camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Preben Asmussen (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CAMEL-4876) Add support for a "back-off multiplier" capability to the ScheduledPollConsumer
Date Thu, 01 Aug 2013 19:55:48 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-4876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13726751#comment-13726751
] 

Preben Asmussen edited comment on CAMEL-4876 at 8/1/13 7:54 PM:
----------------------------------------------------------------

[~davsclaus]
Another way this could be usefull ->
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
                
      was (Author: preben):
    [~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

Mime
View raw message