[jira] Commented: (SMXCOMP-98) smx-jms async consumer needs dynamic mechanism to throttle message consumption

["Ron Gavlin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/activemq/browse/SMXCOMP-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51319#action_51319 ] 

Ron Gavlin commented on SMXCOMP-98:
-----------------------------------

Greetings,

Apache CXF has completed an initial implementation for dynamically throttling async jms message consumption (see https://issues.apache.org/jira/browse/CXF-2002). What are your thoughts on the approach taken by CXF? Do you think a similar technique would be appropriate for resolving this issue? 

BTW, it would seem useful to be able to pause the Spring JMS listener by setting concurrentConsumers to 0. Currently, the concurrentConsumers value must be >= 1. Would it make sense to bring this up with the Spring folks on their forums?

Regards,

/Ron

> smx-jms async consumer needs dynamic mechanism to throttle message consumption
> ------------------------------------------------------------------------------
>
>                 Key: SMXCOMP-98
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-98
>             Project: ServiceMix Components
>          Issue Type: New Feature
>          Components: servicemix-jms
>    Affects Versions: servicemix-jms-2008.01
>            Reporter: Ron Gavlin
>
> Currently, the async smx-jms:consumer 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 smx-jms:consumer will overload the smx nmr with message exchanges resulting in problems. A dynamic throttling mechanism on the async smx-jms consumer is required to avoid this problem.
> One possible implementation might as follows:
> First, add a property "maxPendingAsyncExchanges" to the new smx-jms:consumer endpoint. Then add support in the endpoint to track the total number of pending/in-progress exchanges, i.e., the number of exchanges for which no DONE/ERROR has been returned. When this value reaches "maxPendingAsyncExchanges", then the runtime would set the Spring JMS "concurrentConsumers" value to 0. Once the number of "pending" exchanges drops below the "maxPendingAsyncExchanges" threshold, the "concurrentConsumers" value would be increased to a value greater than 0.
> This is the type of dynamic throttling I was envisioning. Thoughts?

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