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

ASF GitHub Bot commented on STORM-495:
--------------------------------------

Github user rick-kilgore commented on the pull request:

    https://github.com/apache/storm/pull/254#issuecomment-57557727
  
    @ptgoetz I think I misunderstood your request at first - I merged 
everything into master in my fork instead of the "retries" branch, because I 
thought that was a requirement for some reason.  I realize now you just meant 
to merge the latest changes from your master.
    
    My fork now has these same changes merged with the latest from master in 
both my master and my retries branch, so you can merge from either.  Sorry 
about the noise.  I'm guessing you'll choose to merge from this one, since it 
has the history of comments, so I'll close the other once you do.


> Add delayed retries to KafkaSpout
> ---------------------------------
>
>                 Key: STORM-495
>                 URL: https://issues.apache.org/jira/browse/STORM-495
>             Project: Apache Storm
>          Issue Type: Improvement
>    Affects Versions: 0.9.3
>         Environment: all environments
>            Reporter: Rick Kilgore
>            Priority: Minor
>              Labels: kafka, retry
>
> If a tuple in the topology originates from the KafkaSpout from the 
> external/storm-kafka sources, and if a bolt in the topology indicates a 
> failure by calling fail() on its OutputCollector, the KafkaSpout will 
> immediately retry the message.
> We wish to use this failure and retry behavior in our ingestion system 
> whenever we experience a recoverable error from a downstream system, such as 
> a 500 or 503 error from a service we depend on.  But with the current 
> KafkaSpout behavior, doing so results in a tight loop where we retry several 
> times over a few seconds and then give up.  I want to be able to delay retry 
> to give the downstream service some time to recover.  Ideally, I would like 
> to have configurable, exponential backoff retry.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to