[
https://issues.apache.org/jira/browse/STORM-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16726414#comment-16726414
]
Roshan Naik commented on STORM-2359:
------------------------------------
{quote}If we were to move timeouts entirely to the acker, there would be a
potential for "lost" tuples (ones that end up not being reemitted) if messages
between the acker and spout get lost.
* The spout may emit a new tuple, and try to notify the acker about it. If
this message is lost, the acker doesn't know about the tuple, and thus can't
time it out.
{quote}
Acker will be totally clueless if all acks from downstream bolts are also lost
for the same tuple tree.
{quote}We can move the timeout logic to the acker,
{quote}
Alternatives :
1) Handle timeouts in SpoutExecutor. It sends a timeout msg to ACKer.
*+Benefit+*: May not be any better than doing in ACKer. Do you have any
thoughts about this ?
2) Eliminate timeout communication between Spout & ACK. Let each does its own
timeout. *+Benefit+*: Eliminates need for:
* Periodic sync up msgs (also avoid possibility of latency spikes in multi
worker mode when these msgs get large).
* A - B calculation, as well as
* timeout msg exchanges.
TimeoutReset msgs can still be supported.
-roshan
> 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
> Assignee: Stig Rohde Døssing
> Priority: Major
> Attachments: STORM-2359.ods
>
>
> 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
(v7.6.3#76005)
