cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <>
Subject [jira] Commented: (CXF-2002) Server async jms transport needs dynamic mechanism to throttle message consumption
Date Fri, 17 Apr 2009 16:08:14 GMT


Sergey Beryozkin commented on CXF-2002:

Ron -

I've merged what I believe may fix it for you to 

trunk :
2.1.x :
2.0.x :

Can you please give me a favor and verify the problem has been solved ?

I decided to go with the idea of swapping the selectors as needed. I thought the idea of blocking
the request threads would achieve nothing as that per se would not prevent the other request
threads filling in the memory with other messages. I may get back to it if the existing fix
proves to be unreliable but I do hope it will work ok.

here's the example of the spring configuration :

<jms:destination name="{}HelloContinuationPort.jms-destination">
      <jms:address jndiConnectionFactoryName="ConnectionFactory" 
                   <jms:JMSNamingProperty name="java.naming.factory.initial" value="org.apache.activemq.jndi.ActiveMQInitialContextFactory"/>
                   <jms:JMSNamingProperty name="java.naming.provider.url" value="tcp://localhost:61500"/>

  <bean id="jmsConf2" class="org.apache.cxf.transport.jms.JMSConfiguration"


if (p:cacheLevel >=3 ) (org.springframework.jms.listener.DefaultMessageListenerContainer.CACHE_CONSUMER)

then p:maxSuspendedContinuations will be ignored as the BOGUS_SELECTOR won't be taken into
account anyway

Currently, only that Continuation instance which replaced the current MessageSelector with
 BOGUS_SELECTOR will be able to put it back. Thus it will not be replaced immediately when
the number of continuations dropped down due to other instances being resumed and finished.
I'm thinking it's not too bad - when the load is high the selector updates will be less chatty.
Perhaps we will be able to optimize it by sharing an original selector value between various
continuation instances so as soon as the number of continuations is less than max then the
selector will be restored...

cheers, Sergey

Cheers, Sergey

> Server async jms transport needs dynamic mechanism to throttle message consumption
> ----------------------------------------------------------------------------------
>                 Key: CXF-2002
>                 URL:
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.9, 2.1.3, 2.0.10
>            Reporter: Ron Gavlin
>            Assignee: Sergey Beryozkin
>             Fix For: 2.2.1
> Currently, the server-side async jms transport has no mechanism to throttle consumption
of incoming messages. This becomes problematic in scenarios where a large backlog of messages
exists on the input queue. In this case, it is likely that the cxf server will overload its
internal work item queues resulting in problems. A dynamic throttling mechanism on the async
jms server is required to avoid this problem.

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

View raw message