You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Ron Gavlin (JIRA)" <ji...@apache.org> on 2009/01/25 13:41:05 UTC
[jira] Updated: (SM-1777) smx-jms async consumer needs dynamic
mechanism to throttle message consumption
[ https://issues.apache.org/activemq/browse/SM-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ron Gavlin updated SM-1777:
---------------------------
Description:
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?
was:
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 the 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?
> smx-jms async consumer needs dynamic mechanism to throttle message consumption
> ------------------------------------------------------------------------------
>
> Key: SM-1777
> URL: https://issues.apache.org/activemq/browse/SM-1777
> Project: ServiceMix
> 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.