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

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

Github user revans2 commented on a diff in the pull request:

    https://github.com/apache/storm/pull/1174#discussion_r54731300
  
    --- Diff: storm-core/src/jvm/org/apache/storm/daemon/Acker.java ---
    @@ -100,6 +101,8 @@ public void execute(Tuple input) {
                 }
                 curr.failed = true;
                 pending.put(id, curr);
    +        } else if(ACKER_RESET_TIMEOUT_STREAM_ID.equals(streamId)) {
    --- End diff --
    
    Yes this is very true, in the clj code the entire processing was wrapped in 
a null check for curr.


> Add support for extending tuple tree timeout
> --------------------------------------------
>
>                 Key: STORM-1549
>                 URL: https://issues.apache.org/jira/browse/STORM-1549
>             Project: Apache Storm
>          Issue Type: New Feature
>          Components: storm-core
>            Reporter: Stig Rohde Døssing
>            Assignee: Stig Rohde Døssing
>            Priority: Minor
>
> During the discussion of https://github.com/apache/storm/pull/700 the issue 
> of allowing timeout extension in case of unavailable external components 
> (such as a web service) came up.
> The current implementation makes tuples fail at a set interval, regardless of 
> whether or not replaying them is necessary. This can be irritating in 
> topologies that emit to multiple services, since one hanging service will 
> cause replays to hit all the working services as well.
> I suggest adding a resetTimeout function to IOutputCollector, which will make 
> the relevant ackers and spouts reinsert the tuple tree information in their 
> pending maps. 
> The intended usage is that a bolt can call this function on an interval if it 
> needs to delay expiration, for example if it needs to retry calling a web 
> server a few times. It may also be useful for slow topologies that want Storm 
> to detect hanging/dropped tuples faster than the max expected complete 
> latency of the topology.



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

Reply via email to