[
https://issues.apache.org/jira/browse/CXF-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700226#action_12700226
]
Sergey Beryozkin commented on CXF-2002:
---------------------------------------
Ron -
I've merged what I believe may fix it for you to
trunk : http://svn.apache.org/viewvc?rev=766013&view=rev
2.1.x : http://svn.apache.org/viewvc?rev=766045&view=rev
2.0.x : http://svn.apache.org/viewvc?rev=766061&view=rev
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="{http://cxf.apache.org/systest/jaxws}HelloContinuationPort.jms-destination";>
<jms:address jndiConnectionFactoryName="ConnectionFactory"
jndiDestinationName="dynamicQueues/test.jmstransport.text">
<jms:JMSNamingProperty name="java.naming.factory.initial"
value="org.apache.activemq.jndi.ActiveMQInitialContextFactory"/>
<jms:JMSNamingProperty name="java.naming.provider.url"
value="tcp://localhost:61500"/>
</jms:address>
<jms:jmsConfig-ref>jmsConf2</jms:jmsConfig-ref>
</jms:destination>
<bean id="jmsConf2" class="org.apache.cxf.transport.jms.JMSConfiguration"
p:connectionFactory-ref="jmsConnectionFactory"
p:timeToLive="500000"
p:concurrentConsumers="1"
p:maxConcurrentConsumers="1"
p:maxSuspendedContinuations="1"
p:cacheLevel="2"
/>
Note
p:maxSuspendedContinuations="1"
p:cacheLevel="2"
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: https://issues.apache.org/jira/browse/CXF-2002
> 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.
