cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Hadrosek (JIRA)" <>
Subject [jira] Updated: (CXF-2343) Improve Message Performance Under High Volume with Low Latency Consumers
Date Thu, 16 Jul 2009 11:32:16 GMT


Paul Hadrosek updated CXF-2343:

    Attachment: cxf.patch

Code to replace bogus message selector.

> Improve Message Performance Under High Volume with Low Latency Consumers
> ------------------------------------------------------------------------
>                 Key: CXF-2343
>                 URL:
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>            Reporter: Paul Hadrosek
>         Attachments: cxf.patch
> 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.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message