You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Preben Asmussen (JIRA)" <ji...@apache.org> on 2013/08/01 21:01:51 UTC
[jira] [Commented] (CAMEL-4876) Add support for a "back-off
multiplier" capability to the ScheduledPollConsumer
[ https://issues.apache.org/jira/browse/CAMEL-4876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13726751#comment-13726751 ]
Preben Asmussen commented on CAMEL-4876:
----------------------------------------
[~davsclaus]
Another way this could be use full ->
If repeated errors occur, the poll could use the backoffMultiplier feature to auto delay the next poll.
We could introduce options to control this e.g. autoBackOffOnError=true/false, numberOfErrorsBeforeBackoff in combination with the other new backOff options.
When combining this with consumer.bridgeErrorHandler you would have a nice way for consumer endpoints to deal with failing infrastructure.
I would even go so far to say that autoBackOff should be enabled by default on 3.0
> Add support for a "back-off multiplier" capability to the ScheduledPollConsumer
> -------------------------------------------------------------------------------
>
> Key: CAMEL-4876
> URL: https://issues.apache.org/jira/browse/CAMEL-4876
> Project: Camel
> Issue Type: New Feature
> Reporter: Ashwin Karpe
> Fix For: 2.12.0
>
>
> Usually files or tables are only updated once a day or even once a week in a batch like fashion. When this happens its of course important to process as fast as possible (using the default 500 ms delay), but most of the time when there is no activity, polling every 500 ms. is not necessary and takes system resources when running many polling routes on the same box.
> I was thinking that the ScheduledPollConsumer could be more dynamic by introducing a new option eg. backoffMultiplier, that resets the scheduler to maxDelay if a poll results in no exchange (maybe after x polls with no results).
> The same goes if a poll results in an exchange, and the delay currently is at backoffMultiplier the scheduler is reset to the original delay thereby polling more agresive again.
> Original Camel User Forum request : http://camel.465427.n5.nabble.com/DISCUSS-Dynamic-ScheduledPollConsumer-td5129231.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira