I have two comments to add:
1) Is there any JIRA for invalid metrics values? I did not see one. I am
running with bolts having breakpoints and long before my bolts are every
entered, the metrics indicate that these bolts already have more than 100
emits. I have thought to raise a JIRA on this but I am not sure what I would
add for details. Would some specific debug output aid in resolving this?
2) For acks, is there any possibility of adding tracking for acks that happen
after a timeout? I can step into my bolt each time it is called and confirm
that it is acking each request, yet the acks do not match the emits (which
should have a 1 to 1 ratio). I am guessing that this is because the ack
happened too late or it might be incorrect metrics total.
I use the STORM UI for processing tracking.
Thanks,
Jason
From: Nathan Leung <[email protected]>
To: user <[email protected]>
Sent: Monday, February 23, 2015 11:56 AM
Subject: Re: Question About Emitted, Transferred and Acked Bolts
executed = # of times you called executedacked = # of executed tuples that you
acked; ideally this will match executedemitted = # of tuples that you emitted;
if you call emit more than once per execute call this can be higher than
execute counttransferred = # of tuples transferred downstream; if you have 2
bolts subscribing to your bolt, then this count can be higher than emitted.
On Mon, Feb 23, 2015 at 11:35 AM, Rahul Reddy <[email protected]> wrote:
Hi,
Can you guys help me understand difference between emitted, transferred and
acked tuples.
In my case every tuple emitted by ablog-filter-bolt will be processed by
ablog-flatten-xml-bolt which will then be written by ablog-hdfs-bolt to hdfs.
Ideally all metrics for executed/acked should match after tuples are emitted
from ablog-filter-bolt . I'm not sure why there is so much discrepancy in
emitted/transferredacked tuple count between these bolts although it dosent
show any failed tuples.
Any ideas what I can check and how to interpret metrics correctly?
Thanks
Rahul
