[
https://issues.apache.org/jira/browse/STORM-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041851#comment-16041851
]
Roshan Naik commented on STORM-2359:
------------------------------------
{quote} In order to reduce load on the spout, we should try to "bundle up"
these resets in the acker bolts before sending them to the spout {quote}
The resets are managed internally by the ACKer bolt. The spout only gets
notified if the timeout expires or if tuple-tree is fully processed.
{quote}When tuples are stuck in queues behind other tuples{quote}
That case would be more accurately classified as "progress is being made" ...
but slower than expected.
The case of 'progress is not being made' is when a worker that is processing
part of the tuple tree dies.
{quote}If a bolt is taking longer to process a tuple than expected, it can be
solved in the concrete bolt implementation by using
OutputCollector.resetTimeout at an appropriate interval (e.g. the tuple timeout
minus a few seconds).{quote}
I think you are trying to mitigate the number of resets being sent to Spout...
but like i mentioned before reset are never sent to spout.
> Revising Message Timeouts
> -------------------------
>
> Key: STORM-2359
> URL: https://issues.apache.org/jira/browse/STORM-2359
> Project: Apache Storm
> Issue Type: Sub-task
> Components: storm-core
> Affects Versions: 2.0.0
> Reporter: Roshan Naik
>
> A revised strategy for message timeouts is proposed here.
> Design Doc:
>
> https://docs.google.com/document/d/1am1kO7Wmf17U_Vz5_uyBB2OuSsc4TZQWRvbRhX52n5w/edit?usp=sharing
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
