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

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

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

    https://github.com/apache/storm/pull/1174#discussion_r54685209
  
    --- 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 --
    
    This introduces a NPE scenario because earlier in all the if blocks, if 
curr was null, it was getting initialized. Now curr.spoutTask will throw NPE if 
reset timeout comes before init or after init times out. This can be avoided by 
adding below just before `pending.put(id, curr)`
    ```
    if (curr == null) {
         curr = new AckObject();
    }
    ```


> 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