Github user revans2 commented on the pull request:
https://github.com/apache/storm/pull/700#issuecomment-144723285
@rsltrifork, No this does not solve that issue. The timeout is still a
hard coded value. The backpressure just means that the spout will not be
outputting new values. Old tuples can still time out and be replayed. The
problem here is the halting problem. How do you know that the bolt is waiting
in a controlled manner? Even if you do know that how do you know that if it is
waiting in a controlled manner that it has not lost track of a tuple? You have
to be able to predict the future to truly solve this problem. A hard coded
timeout is a simple solution. There have been a few other proposals to adjust
the timeout dynamically, but that all have potentially serious limitations
compared to a static timeout.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
