[ 
https://issues.apache.org/jira/browse/CXF-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699637#action_12699637
 ] 

Sergey Beryozkin commented on CXF-2002:
---------------------------------------

Hi Ron

> What would you think about setting a bogus selector on the 
> DefaultMessageListenerContainer to suspend message consumption?  That appears 
> to be the technique used to implement JMS-based throttling in the new SMX4 
> Cluster Endpoint

Sounds like a neat idea. Suppose we just set some bogus selector like 
"org.apache.cxf.jms.continuations.too-many" so it will keep the incoming 
messages in the queue till the original selector is restored. 

I was also thinking about simply blocking the request threads for the time 
specified in suspend() - it would keep the JMS thread blocked and thus all the 
existing JMS request threads will eventually be locked till a number of 
continuations decreases - but I'm not 100% sure it would actually prevent the 
JMS runtime from creating new JMS threads which would continue pump new 
messages into the memory.

What do you think about this second idea ?
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.

Reply via email to