Mailing-List: contact user-help@storm.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@storm.apache.org
MIME-Version: 1.0
In-Reply-To: <CAGtN-M+u2s0+X-JoOza-wv1EY2eQ-DGp_RmWZUydipYnd0DwHQ@mail.gmail.com>
References: <CAGtN-M+u2s0+X-JoOza-wv1EY2eQ-DGp_RmWZUydipYnd0DwHQ@mail.gmail.com>
From: =?UTF-8?Q?Stig_Rohde_D=C3=B8ssing?= <srdo@apache.org>
Date: Fri, 3 Nov 2017 16:17:21 +0100
Message-ID: <CAG09ER1BxFAmRdAM60479ryxjDRrB68Hv_M52fTkJgXYBLhcRA@mail.gmail.com>
Subject: Re: Emitting tuples anchored to already-acked tuples
To: user@storm.apache.org
Content-Type: multipart/alternative; boundary="94eb2c0a243aec3b16055d1599aa"
archived-at: Fri, 03 Nov 2017 15:17:24 -0000

--94eb2c0a243aec3b16055d1599aa
Content-Type: text/plain; charset="UTF-8"

Hi,

It depends a bit on which order the acker bolt sees the messages.

When bolt B acks the tuple, it sends a value to the acker bolt that
essentially communicates "I'm done with tuple 123, and I didn't emit any
new tuples anchored to it". Please read the section "How does Storm
implement reliability in an efficient way" at
https://storm.apache.org/releases/2.0.0-SNAPSHOT/Guaranteeing-message-processing.html
for details.

If the acker receives the ack from bolt B first, it will forward the ack to
the spout and forget about the tuple tree. Any other messages for that
tuple tree will effectively be ignored.

If the acker receives the ack from bolt C first (let's say the ack from B
was delayed for some reason), the tuple ack val won't match up to what the
acker expects. The acker will essentially be receiving acks for tuples it
doesn't know about. Since the acking mechanism is based on acking tuple ids
with themselves to arrive at a value of 0 when the full tree is acked, this
will prevent the tree from being acked. The tuple on the spout will time
out and fail. In case the message from C is a fail, it will act like you
expect and fail the tuple immediately on the spout.

The bottom line is to avoid anchoring new tuples to acked tuples :)

You might find
https://github.com/apache/storm/blob/6207d320c3f79185f5e8e19458d73fbf1aa10f72/storm-client/src/jvm/org/apache/storm/daemon/Acker.java#L80
and
https://github.com/apache/storm/blob/6207d320c3f79185f5e8e19458d73fbf1aa10f72/storm-client/src/jvm/org/apache/storm/executor/bolt/BoltOutputCollectorImpl.java#L79
interesting.

2017-11-03 14:27 GMT+01:00 Lawrence Craft <lawrence.craft@gmail.com>:

> Hi all,
>
> Out of curiosity, what happens if a bolt emits tuples anchored to spout
> tuples that have already been acked?
>
> As an example: Spout A emits tuple with ID 123. Bolt B receives and
> immediately acks tuple 123, but keeps it around in memory. At a later
> point, something triggers Bolt B to emit a tuple anchored to the original
> spout tuple 123. This new tuple is received by Bolt C.
>
> What happens if Bolt C fails this tuple? Or acks it? Will the spout
> receive a duplicate ack (or an ack followed by a fail)?
>
> Thanks,
>
> Lawrence
>

--94eb2c0a243aec3b16055d1599aa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div>Hi,<br></div><div><br></div>=
It depends a bit on which order the acker bolt sees the messages.<br><br></=
div>When bolt B acks the tuple, it sends a value to the acker bolt that ess=
entially communicates &quot;I&#39;m done with tuple 123, and I didn&#39;t e=
mit any new tuples anchored to it&quot;. Please read the section &quot;How =
does Storm implement reliability in an efficient way&quot; at <a href=3D"ht=
tps://storm.apache.org/releases/2.0.0-SNAPSHOT/Guaranteeing-message-process=
ing.html">https://storm.apache.org/releases/2.0.0-SNAPSHOT/Guaranteeing-mes=
sage-processing.html</a> for details.<br><br></div>If the acker receives th=
e ack from bolt B first, it will forward the ack to the spout and forget ab=
out the tuple tree. Any other messages for that tuple tree will effectively=
 be ignored.<br><br></div>If the acker receives the ack from bolt C first (=
let&#39;s say the ack from B was delayed for some reason), the tuple ack va=
l won&#39;t match up to what the acker expects. The acker will essentially =
be receiving acks for tuples it doesn&#39;t know about. Since the acking me=
chanism is based on acking tuple ids with themselves to arrive at a value o=
f 0 when the full tree is acked, this will prevent the tree from being acke=
d. The tuple on the spout will time out and fail. In case the message from =
C is a fail, it will act like you expect and fail the tuple immediately on =
the spout.<br><br></div>The bottom line is to avoid anchoring new tuples to=
 acked tuples :)<br><br></div>You might find <a href=3D"https://github.com/=
apache/storm/blob/6207d320c3f79185f5e8e19458d73fbf1aa10f72/storm-client/src=
/jvm/org/apache/storm/daemon/Acker.java#L80">https://github.com/apache/stor=
m/blob/6207d320c3f79185f5e8e19458d73fbf1aa10f72/storm-client/src/jvm/org/ap=
ache/storm/daemon/Acker.java#L80</a> and <a href=3D"https://github.com/apac=
he/storm/blob/6207d320c3f79185f5e8e19458d73fbf1aa10f72/storm-client/src/jvm=
/org/apache/storm/executor/bolt/BoltOutputCollectorImpl.java#L79">https://g=
ithub.com/apache/storm/blob/6207d320c3f79185f5e8e19458d73fbf1aa10f72/storm-=
client/src/jvm/org/apache/storm/executor/bolt/BoltOutputCollectorImpl.java#=
L79</a> interesting. <br></div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote">2017-11-03 14:27 GMT+01:00 Lawrence Craft <span dir=3D"ltr">&=
lt;<a href=3D"mailto:lawrence.craft@gmail.com" target=3D"_blank">lawrence.c=
raft@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">Hi all,<div><br></div><div>Out of curiosity, what happens if a bol=
t emits tuples anchored to spout tuples that have already been acked?</div>=
<div><br></div><div>As an example: Spout A emits tuple with ID 123. Bolt B =
receives and immediately acks tuple 123, but keeps it around in memory. At =
a later point, something triggers Bolt B to emit a tuple anchored to the or=
iginal spout tuple 123. This new tuple is received by Bolt C.</div><div><br=
></div><div>What happens if Bolt C fails this tuple? Or acks it? Will the s=
pout receive a duplicate ack (or an ack followed by a fail)?</div><div><br>=
</div><div>Thanks,</div><div><br></div><div>Lawrence</div></div>
</blockquote></div><br></div>

--94eb2c0a243aec3b16055d1599aa--