Github user bastiliu commented on the pull request:
https://github.com/apache/storm/pull/647#issuecomment-157935012
@revans2 Yes, I agree that this checking is helpful to find the problem
spout/bolt. My point here is that the solution could be improved.
1. If timeout, it is better to raise a warning(e.g. give a warning on web
UI). Because we have seen some topologys that might require to block at
execute()/nextTuple() to wait some essential initialization. e.g. the
connection to database in a bolt is down. The user would like to wait untill
the reconnection is done.
2. The triggering mechanism of "last-active-time" timeout should be
updated. Current implementation puts a "last-active-time" tuple to receiving
queue, then spout/bolt update the "last-active-time" when retrieving the
trigger tuple from receiving queue. But it is possible that there already have
been many tuples in receiving queue before putting the "last-active-time"
trigger tuple. So the spout/bolt must process all the tuples which are put into
receiving queue before the trigger tuple. The processing of total topology
tuples might take a long time which probably cause the timeout, even if the
processing time of a tuple is short. From user's point of view, that is
unexpected.
---
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.
---
