Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Message-ID: <1746428161.1247743936816.JavaMail.jira@brutus>
Date: Thu, 16 Jul 2009 04:32:16 -0700 (PDT)
From: "Paul Hadrosek (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Subject: [jira] Updated: (CXF-2343) Improve Message Performance Under High
 Volume with Low Latency Consumers
In-Reply-To: <356161488.1247743694999.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/CXF-2343?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:all-tabpanel ]

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: https://issues.apache.org/jira/browse/CXF-2343
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>            Reporter: Paul Hadrosek
>         Attachments: cxf.patch
>
>
> IT organizations are on constant pressures in improving enterprise messag=
ing systems to deliver and process high volume message traffic. For example=
 financial IT organizations are continually automate, integrate and optimiz=
ed the transaction life cycle. The underlying messaging system must be able=
 to support extremely low latency and very high message throughput with eff=
ective congestion control.    =20
> Message performance testing was performed to evaluate the CXF bogus messa=
ge selector implementation as the best approach in improving message thrott=
ling in a long consumer service process with a very high JMS message traffi=
c volume.
> The intent of the bogus message selector implementation in CXF is to alle=
viate 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 sim=
ulated an ingest driver that produced high volume message traffic with a lo=
ng running CXF consumer service which forced a backlog of messages in the r=
equest queue. The test results illustrated a dramatic degradation in the co=
mmercial JMS message broker processing performance from 12,000 messages per=
 second to 100 messages per second (99.17% degradation of performance). Als=
o it was observed the JMS receiveTimeout parameter was set to the default v=
alue of 1 which contributed to the degradation of performance. CXF was modi=
fied to expose the JMS receiveTimeout parameter as a CXF feature. The test =
scenario was rerun with a receiveTimeout set to 30 seconds which improved m=
essage processing from 100 messages per second to 4,918 messages per second=
.
> To further improve ingest message processing performance; the bogus messa=
ge selector implementation was replaced with a stop and start Spring JMS Li=
stener Container (DefaultMessageListenerContainer) implementation via the C=
XF JMSContinuation class. The JMSContintuation class starts and stops the S=
pring Container based on the maximum suspended continuations parameter. The=
 moment a stop is issued from the JMSContinuation class to the Container, n=
o new messages are allowed to be accepted by the Container until the Contai=
ner completes processing the suspended messages. To avoid message loss whil=
e the Container is in the stop state, CXF features must support the JMS acc=
eptMessagesWhileStopping parameter. This parameter must be set to true to n=
otify the Container not to reject messages while in the stop state. The tes=
t scenario was rerun using the CXF start/stop Container implementation with=
 a commercial JMS message broker. The test results demonstrated that messag=
e processing performance improved from 4,918 messages per second to 8,333 m=
essages per second.
> Based on the test results, I concluded that the start/stop Container impl=
ementation is the recommended solution for improving message performance in=
 high JMS message traffic with low latency consumers. The start/stop Contai=
ner implementation improved message processing performance over the bogus m=
essage selector implementation by 28%.
> See attachment for patch.

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