[ https://issues.apache.org/jira/browse/STORM-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186823#comment-15186823 ]
ASF GitHub Bot commented on STORM-1549: --------------------------------------- Github user rsltrifork commented on the pull request: https://github.com/apache/storm/pull/1174#issuecomment-194200201 As all review comments are addressed, will it be merged soon? :-) We need this feature in the IoT storm topology we're building, where bolts send to unstable external systems and we need at-least-once consistency, so dropping tuples on tuple timeout is bad for us. > 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)