Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
IT organizations are on constant pressures in improving enterprise messaging systems to deliver and process high volume message traffic. For example financial IT organizations are continually automate, integrate and optimized the transaction life cycle. The underlying messaging system must be able to support extremely low latency and very high message throughput with effective congestion control.
Message performance testing was performed to evaluate the CXF bogus message selector implementation as the best approach in improving message throttling in a long consumer service process with a very high JMS message traffic volume.
The intent of the bogus message selector implementation in CXF is to alleviate message throttling by delegating incoming messages to under performed consumer services. Testing was performed on the CXF bogus message selector implementation with a commercial JMS message broker. The test scenario simulated an ingest driver that produced high volume message traffic with a long running CXF consumer service which forced a backlog of messages in the request queue. The test results illustrated a dramatic degradation in the commercial JMS message broker processing performance from 12,000 messages per second to 100 messages per second (99.17% degradation of performance). Also it was observed the JMS receiveTimeout parameter was set to the default value of 1 which contributed to the degradation of performance. CXF was modified to expose the JMS receiveTimeout parameter as a CXF feature. The test scenario was rerun with a receiveTimeout set to 30 seconds which improved message processing from 100 messages per second to 4,918 messages per second.
To further improve ingest message processing performance; the bogus message selector implementation was replaced with a stop and start Spring JMS Listener Container (DefaultMessageListenerContainer) implementation via the CXF JMSContinuation class. The JMSContintuation class starts and stops the Spring Container based on the maximum suspended continuations parameter. The moment a stop is issued from the JMSContinuation class to the Container, no new messages are allowed to be accepted by the Container until the Container completes processing the suspended messages. To avoid message loss while the Container is in the stop state, CXF features must support the JMS acceptMessagesWhileStopping parameter. This parameter must be set to true to notify the Container not to reject messages while in the stop state. The test scenario was rerun using the CXF start/stop Container implementation with a commercial JMS message broker. The test results demonstrated that message processing performance improved from 4,918 messages per second to 8,333 messages per second.
Based on the test results, I concluded that the start/stop Container implementation is the recommended solution for improving message performance in high JMS message traffic with low latency consumers. The start/stop Container implementation improved message processing performance over the bogus message selector implementation by 28%.
See attachment for patch.