Return-Path: X-Original-To: apmail-storm-user-archive@minotaur.apache.org Delivered-To: apmail-storm-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 94DF217AB8 for ; Mon, 23 Feb 2015 22:02:57 +0000 (UTC) Received: (qmail 29144 invoked by uid 500); 23 Feb 2015 22:02:56 -0000 Delivered-To: apmail-storm-user-archive@storm.apache.org Received: (qmail 29102 invoked by uid 500); 23 Feb 2015 22:02:56 -0000 Mailing-List: contact user-help@storm.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@storm.apache.org Delivered-To: mailing list user@storm.apache.org Received: (qmail 29092 invoked by uid 99); 23 Feb 2015 22:02:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Feb 2015 22:02:56 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [98.136.216.240] (HELO nm33-vm1.bullet.mail.gq1.yahoo.com) (98.136.216.240) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Feb 2015 22:02:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ymail.com; s=s2048; t=1424728759; bh=l+sattQR1hPgMglfj8HzLOlktg+Krkyjn0+arpPgsNg=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=PwGAmSK4pbkv4I6/m7N6rFhtZtY1ce8hHY4OP+btttUizZ6p8T1hxWzTTYneEHSRlj+SYNM04ELaLWCAm9bKExYIFnFHgu41wyZkjBldAHbNi1W5uTtXvMewnpepEjqAC1aUk5ONPIIAL94UflYb1ezkN+LIhbrY7bww1KDKFOPBfEnphFOoE4K17v8lt6tMLxR8r4t/ml8/DEYAu2hv1VimD/kdexRmYW1oSSvprPnJzAiBVfIh6DdlID3eI2DGcx+wZ1gS2Os9aEgRZQp2lvqHEp4ENKUDF+i/tDfXH0WsiCZKUYKY1+WLHSrtEAD9blnNDnzQCbTjfUnlq4SMFw== Received: from [127.0.0.1] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 23 Feb 2015 21:59:19 -0000 Received: from [98.137.12.188] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 23 Feb 2015 21:56:17 -0000 Received: from [98.139.214.32] by tm9.bullet.mail.gq1.yahoo.com with NNFMP; 23 Feb 2015 21:56:17 -0000 Received: from [98.139.212.214] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 23 Feb 2015 21:56:16 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 23 Feb 2015 21:56:16 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 943375.54662.bm@omp1023.mail.bf1.yahoo.com X-YMail-OSG: zVS_9KoVM1l37IBDB3VaezxH6ZS00SXYswXbMbNpFAnejQD06_AQQdynNx2LCF0 .vKPcJVgkAjN6pWCEUPVMcitZus3su7VY8QQLmoOcDoUP2N5Dwm6ktoXSX4V_IntmKEF9Isbm4.5 0JzJ58GtIDIXClskK1bfaQfBxww2uFe0G_mp2B9vbBatvOd9NqEuwjhEi.WQ6of6MzonHyEJF35p cNpY.U4MC9_Ondjx.xdo7cgMzwRVbiyemJmXPvauYPvnOFL.OzCOhc7.paJW3aG3lVlQR0O2txm5 O4US2S2pphsTG5DMPdWQJqDPuNNQ1A6YkXiptlur91J5ZhWHCt9qYw2FCAsht46wGuos2L1JF3Xo buQjQskTjEGLxUMwdqOvgl73.j4nLbGauNYYAvun10yXNoO0g6U9QjswukP7y8Z0HgIaBnMnxBvH pMFoxpYMPk_p.1uxyMqeivTWRybJHkL64JI5QojWsEnbR.tQzRoHXC02GpgxujtkWRfIsXWQZal6 .iTMxjsHjBhvx1fwZVj20Tg7J1EwAC6sMEBNoHnBq7Uf0alhgvk6UjkTviH1vSL6dRh8bildKI9W zPRErCmC1vDdXD2lkQ5qJhnx_2c3TCQ-- Received: by 76.13.26.108; Mon, 23 Feb 2015 21:56:16 +0000 Date: Mon, 23 Feb 2015 21:56:15 +0000 (UTC) From: Jason Kania Reply-To: Jason Kania To: Nathan Leung , user Message-ID: <1761347935.8561959.1424728575638.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: Subject: Re: Question About Emitted, Transferred and Acked Bolts MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8561958_98989531.1424728575618" X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_8561958_98989531.1424728575618 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nathan, I only get spout failures. None of my bolts fail. Are all failures on a spo= ut going to be associated with timeout? If not, how would one know the diff= erence? Hence my question about whether it would be possible to track timed= -out acks explicitly. Thanks, Jason From: Nathan Leung To: user ; Jason Kania =20 Sent: Monday, February 23, 2015 4:52 PM Subject: Re: Question About Emitted, Transferred and Acked Bolts =20 If your processing takes a long time they may be timing out. On Mon, Feb 23, 2015 at 4:35 PM, Jason Kania wrote: Thanks for the suggestion. My traffic is only one or two tuples per second = in the current environment so I would not expect that to be the problem. I = do have failures. Hence, I was wondering if slow acking was the problem. In= stepping through the processing, I know the failures aren't in the bolts t= hemselves. That is why I thought it strange. From: Michael Rose To: "user@storm.apache.org" ; Jason Kania =20 Sent: Monday, February 23, 2015 4:24 PM Subject: Re: Question About Emitted, Transferred and Acked Bolts =20 Do you have enough ackers to keep up with your traffic? How about failures? Michael RoseSenior Software EngineerFullContact=C2=A0|=C2=A0fullcontact.com= m: +1.720.837.1357=C2=A0| t:=C2=A0@xorlev All Your Contacts, Updated and In One Place.Try FullContact for Free On Mon, Feb 23, 2015 at 2:16 PM, Jason Kania wrote: Michael, That's good to know. I was unaware. That said, if execution of a bolt has n= ot occurred, I would still expect a 0 emit count and acks not to be falling= behind the emits by much. My acks are half my emits. From: Michael Rose To: "user@storm.apache.org" ; Jason Kania =20 Sent: Monday, February 23, 2015 3:52 PM Subject: Re: Question About Emitted, Transferred and Acked Bolts =20 Keep in mind that those metrics are sampled at the rate of=C2=A0topology.st= ats.sample.rate, 0.05 by default. If you turn it up to 1.0 you'll see full-= resolution, though at the price of more time spent collecting metrics. Michael RoseSenior Software EngineerFullContact=C2=A0|=C2=A0fullcontact.com= m: +1.720.837.1357=C2=A0| t:=C2=A0@xorlev All Your Contacts, Updated and In One Place.Try FullContact for Free On Mon, Feb 23, 2015 at 12:14 PM, Jason Kania wrote= : I have two comments to add: 1) Is there any JIRA for invalid metrics values? I did not see one. I am ru= nning with bolts having breakpoints and long before my bolts are every ente= red, 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 happ= en after a timeout? I can step into my bolt each time it is called and conf= irm that it is acking each request, yet the acks do not match the emits (wh= ich 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 To: user =20 Sent: Monday, February 23, 2015 11:56 AM Subject: Re: Question About Emitted, Transferred and Acked Bolts =20 executed =3D # of times you called executedacked =3D # of executed tuples t= hat you acked; ideally this will match executedemitted =3D # of tuples that= you emitted; if you call emit more than once per execute call this can be = higher than execute counttransferred =3D # of tuples transferred downstream= ; if you have 2 bolts subscribing to your bolt, then this count can be high= er than emitted. On Mon, Feb 23, 2015 at 11:35 AM, Rahul Reddy 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 ab= log-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 emitt= ed from ablog-filter-bolt . I'm not sure why there is so much discrepancy i= n emitted/transferredacked tuple count between these bolts although it dose= nt show any failed tuples. Any ideas what I can check and how to interpret metrics correctly? Thanks Rahul =20 =20 =20 ------=_Part_8561958_98989531.1424728575618 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nathan,

I only get spout failures. None of my bolts fail. Are all failures= on a spout going to be associated with timeout? If not, how would one know= the difference? Hence my question about whether it would be possible to tr= ack timed-out acks explicitly.

Thanks,

Jas= on

From: Nathan Le= ung <ncleung@gmail.com>
To:= user <user@storm.apache.org>; Jason Kania <jason.kania= @ymail.com>
Sent: = Monday, February 23, 2015 4:52 PM
Subject: Re: Question About Emitted, Transferred and Acked Bolt= s

I= f your processing takes a long time they may be timing out.



On Mon, Feb 23, 2= 015 at 4:35 PM, Jason Kania <jason.kania@ymail.com> wrot= e:
Thank= s for the suggestion. My traffic is only one or two tuples per second in th= e current environment so I would not expect that to be the problem. I do ha= ve failures. Hence, I was wondering if slow acking was the problem. In step= ping through the processing, I know the failures aren't in the bolts themse= lves. That is why I thought it strange.

<= hr size=3D"1"> From: Michael Rose <michael@fullcontact.= com>
To: "user@storm.apache.org" <user@storm.apache.org>= ;; Jason Kania <jason.kania@ymail.com>
Sent: Monday, February 23, 2015 4:24 PM

Subject: Re: Question About Emitte= d, Transferred and Acked Bolts

Do you have enough ackers to keep up with your traffi= c? How about failures?
Michael Rose
Senior Software E= ngineer
FullContact | fullcontact.com
m: +1.720.837.1357 | t:&nb= sp;@xorlev


All Your Contacts, Updated and In One Place.=
=



On Mon, Feb 23, 2015 at 2:16 PM, Jason Kania <jason.kania@ymail.com> wrote:
Michael,

That's good to know. I was unaware. That said, i= f execution of a bolt has not occurred, I would still expect a 0 emit count= and acks not to be falling behind the emits by much. My acks are half my e= mits.

=
From: Michael Rose <michael@fullcontact.com= >
To:= "user@storm.a= pache.org" <user@storm.apache.org>; Jason Kania <jason.kania@ymail.com>
Sent: Monday, Fe= bruary 23, 2015 3:52 PM

Subject: Re: Question About Emitted, Tran= sferred and Acked Bolts

Keep in mind that those me= trics are sampled at the rate of topology.stats.sample.rate, 0.05 by d= efault. If you turn it up to 1.0 you'll see full-resolution, though at the = price of more time spent collecting metrics.

<= div dir=3D"ltr">
Mich= ael Rose
Senior Software Engineer
FullContact <= /span>| = fullcontact.com
m: +1.720.83= 7.1357 | t: @xorlev


All Your Contacts, Up= dated and In One Place.
<= /div>



On Mon, Feb 23, 2015 at 12:14 PM, Jason Kania <jason.kania@ymail.com<= /a>> wrote:
I have two comments to add:

1) Is there any JIRA for inv= alid metrics values? I did not see one. I am running with bolts having brea= kpoints and long before my bolts are every entered, the metrics indicate th= at 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 spe= cific debug output aid in resolving this?

2) For acks, is there any possibility of adding tracking for acks that hap= pen after a timeout? I can step into my bolt each time it is called and con= firm that it is acking each request, yet the acks do not match the emits (w= hich should have a 1 to 1 ratio). I am guessing that this is because the ac= k happened too late or it might be incorrect metrics total.

= I use the STORM UI for processing tracking.
=

Thanks,

Jason

executed =3D # of times you cal= led executed
acked =3D # of executed tuples that you acked; ideally thi= s will match executed
emitted =3D # of tuples that you emitted; i= f you call emit more than once per execute call this can be higher than exe= cute count
transferred =3D # of tuples transferred downstream; if= you have 2 bolts subscribing to your bolt, then this count can be higher t= han emitted.



On Mon, Feb 23, 2015 at 11:35 AM, Rahul Red= dy <Rahul.Reddy@match.com> 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 ab= log-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 emitt= ed from ablog-filter-bolt . I'm not sure why there is so much discrepancy i= n emitted/transferredacked tuple count between these bolts although it dose= nt show any failed tuples.

Any ideas what I can check and how to interpret metrics correctly?

Thanks
Rahul






=





------=_Part_8561958_98989531.1424728575618--