[jira] Updated: (SM-1789) smx-file async FilePollerEndpoint needs a throttling mechanism to avoid creating excessive numbers of open exchanges and overloading the nmr

["Chris Custine (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/activemq/browse/SM-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Custine updated SM-1789:
------------------------------

    Component/s:     (was: servicemix-jms)
                 servicemix-file
       Assignee: Chris Custine

> smx-file async FilePollerEndpoint needs a throttling mechanism to avoid creating excessive numbers of open exchanges and overloading the nmr
> --------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SM-1789
>                 URL: https://issues.apache.org/activemq/browse/SM-1789
>             Project: ServiceMix
>          Issue Type: Bug
>          Components: servicemix-file
>    Affects Versions: servicemix-file-2008.01
>            Reporter: Ron Gavlin
>            Assignee: Chris Custine
>            Priority: Critical
>
> now that the smx-file poller is asynchronous, i run into saturation problems when several thousand files exist in the polled directory at startup. This is similar to the problems I encounter in the async smx-jms consumer when I have thousands of messages on the queue at startup. The jms issue is captured in SM-1777. 
> I suggest that an abstract throttling mechanism be implemented so that config options can be shared across components. I suspect the primary config option would be maxOpenExchanges. When this value is exceeded for the smx-file poller, it would stop polling until the maxOpenExchanges is reduced below maxOpenExchange. For the smx-jms consumer or the cxf-bc jms consumer, setting the Spring JMS concurrentConsumers to 0 would stop consumption.

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