[
https://issues.apache.org/jira/browse/STORM-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16730920#comment-16730920
]
Stig Rohde Døssing edited comment on STORM-2359 at 12/30/18 10:03 AM:
--
The contents of the message is a list of longs (anchor ids). The spout sends
the list of anchors it thinks are pending to the acker. The acker removes any
anchors from the list that are actually pending, and returns the list of
anchors to fail.
Say the spout has emitted messages with anchor ids 1, 3, 4 to acker 1 and
message 2 to acker 2. Say acker 1 has timed out message 1, and acker 2 had
crashed and restarted since receiving message 2. The spout will send [1,3,4] to
acker 1, and [2] to acker 2. The ackers remove any anchor id from the received
lists they recognize and return the modified list to the spout. So acker 1
returns [1] and acker 2 returns [2]. When the spout receives the response
tuple, it will fail the tuples with the received anchor ids, so 1 and 2 will
fail, while 3 and 4 remain pending.
I think the only concern with doing it this way would be how Netty handles
giant messages if the spout pending gets too large. If that's a concern we can
just split the spout messages into smaller chunks.
was (Author: srdo):
The contents of the message is a list of longs (anchor ids). The spout sends
the list of anchors it thinks are pending to the acker. The acker removes any
anchors from the list that are actually pending, and returns the list of
anchors to fail.
Say the spout has emitted messages with anchor ids 1, 3, 4 to acker 1 and
message 2 to acker 2. Say acker 1 has timed out message 1, and acker 2 had
crashed and restarted since receiving message 2. The spout will send [1,3,4] to
acker 1, and [2] to acker 2. The ackers remove any anchor id from the received
lists they recognize and return the modified list to the spout. So acker 1
returns [1] and acker 2 returns [2]. When the spout receives the response
tuple, it will fail the tuples with the received anchor ids, so 1 and 2 will
fail, while 3 and 4 remain pending.
> 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)
