You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@storm.apache.org by Mark Tomko <mt...@broadinstitute.org> on 2015/05/06 00:05:43 UTC
Tuples emitted but not transferred
Hi,
I have a topology that we're working on that seems to have a very long
start-up time, even after the bolts log that they have been prepared.
Looking at the Storm UI, I see tuples that have been "Emitted" but not
"Transferred". The transferred count is 0 for all components, and the
topology has an uptime now of nearly 50 minutes. The logs are free of
exceptions or any other evidence of workers being stopped and started. Does
anyone have any suggestions of what I should look for?
Thanks,
Mark
Re: Tuples emitted but not transferred
Posted by Mark Tomko <mt...@broadinstitute.org>.
I figured the problem out. It's a little embarrassing, but I hope someone
can learn from my mistake! It was related to an initialization order bug in
my own code, resulting in setting the max spout pending to be set to 0 in
some cases. Oops.
On Wed, May 6, 2015 at 5:32 AM, Matthias J. Sax <
mjsax@informatik.hu-berlin.de> wrote:
> If you see an non-zero emitted count, "nextTuple" is definitely called,
> because the emit count is basically the number of tuples given to the
> output collector.
>
> Did you double-check that you have the consumer bolt set up correctly?
> If no consumer "subscribes" to a spout (or bolt) the "transfer-count"
> will always be zero.
>
>
> -Matthias
>
> On 05/06/2015 04:51 AM, Mark Tomko wrote:
> > I'm seeing emits to the metrics stream and no others. It's as if the
> > Storm cluster was simply not calling "nextTuple" on the spout. I've had
> > the topology up for hours at a time.
> >
> > On Tue, May 5, 2015 at 6:13 PM, Jeff Maass <JMaass@cccis.com
> > <ma...@cccis.com>> wrote:
> >
> > It’s my understanding that the #’s cover multiple emitted streams.
> >
> > If you don’t name your stream, and you are using certain “rich”
> > classes - touples will be emitted via the stream named “default”
> >
> > Touples emitted to the ackers are emitted under the __ack_? stream
> >
> > On your topology page in the UI, go all the way to the bottom and
> > click on “Show System Stats”. Maybe the numbers will begin to make
> > sense.
> >
> > Also, you can visualize the stream using the “Show Visualization”
> > button.
> >
> > From: Mark Tomko <mtomko@broadinstitute.org
> > <ma...@broadinstitute.org>>
> > Reply-To: "user@storm.apache.org <ma...@storm.apache.org>"
> > <user@storm.apache.org <ma...@storm.apache.org>>
> > Date: 2015,Tuesday, May 5 at 17:05
> > To: "user@storm.apache.org <ma...@storm.apache.org>"
> > <user@storm.apache.org <ma...@storm.apache.org>>
> > Subject: Tuples emitted but not transferred
> >
> > Hi,
> >
> > I have a topology that we're working on that seems to have a very
> > long start-up time, even after the bolts log that they have been
> > prepared. Looking at the Storm UI, I see tuples that have been
> > "Emitted" but not "Transferred". The transferred count is 0 for all
> > components, and the topology has an uptime now of nearly 50 minutes.
> > The logs are free of exceptions or any other evidence of workers
> > being stopped and started. Does anyone have any suggestions of what
> > I should look for?
> >
> > Thanks,
> > Mark
> >
> >
>
>
Re: Tuples emitted but not transferred
Posted by "Matthias J. Sax" <mj...@informatik.hu-berlin.de>.
If you see an non-zero emitted count, "nextTuple" is definitely called,
because the emit count is basically the number of tuples given to the
output collector.
Did you double-check that you have the consumer bolt set up correctly?
If no consumer "subscribes" to a spout (or bolt) the "transfer-count"
will always be zero.
-Matthias
On 05/06/2015 04:51 AM, Mark Tomko wrote:
> I'm seeing emits to the metrics stream and no others. It's as if the
> Storm cluster was simply not calling "nextTuple" on the spout. I've had
> the topology up for hours at a time.
>
> On Tue, May 5, 2015 at 6:13 PM, Jeff Maass <JMaass@cccis.com
> <ma...@cccis.com>> wrote:
>
> It’s my understanding that the #’s cover multiple emitted streams.
>
> If you don’t name your stream, and you are using certain “rich”
> classes - touples will be emitted via the stream named “default”
>
> Touples emitted to the ackers are emitted under the __ack_? stream
>
> On your topology page in the UI, go all the way to the bottom and
> click on “Show System Stats”. Maybe the numbers will begin to make
> sense.
>
> Also, you can visualize the stream using the “Show Visualization”
> button.
>
> From: Mark Tomko <mtomko@broadinstitute.org
> <ma...@broadinstitute.org>>
> Reply-To: "user@storm.apache.org <ma...@storm.apache.org>"
> <user@storm.apache.org <ma...@storm.apache.org>>
> Date: 2015,Tuesday, May 5 at 17:05
> To: "user@storm.apache.org <ma...@storm.apache.org>"
> <user@storm.apache.org <ma...@storm.apache.org>>
> Subject: Tuples emitted but not transferred
>
> Hi,
>
> I have a topology that we're working on that seems to have a very
> long start-up time, even after the bolts log that they have been
> prepared. Looking at the Storm UI, I see tuples that have been
> "Emitted" but not "Transferred". The transferred count is 0 for all
> components, and the topology has an uptime now of nearly 50 minutes.
> The logs are free of exceptions or any other evidence of workers
> being stopped and started. Does anyone have any suggestions of what
> I should look for?
>
> Thanks,
> Mark
>
>
Re: Tuples emitted but not transferred
Posted by Mark Tomko <mt...@broadinstitute.org>.
I'm seeing emits to the metrics stream and no others. It's as if the Storm
cluster was simply not calling "nextTuple" on the spout. I've had the
topology up for hours at a time.
On Tue, May 5, 2015 at 6:13 PM, Jeff Maass <JM...@cccis.com> wrote:
> It’s my understanding that the #’s cover multiple emitted streams.
>
> If you don’t name your stream, and you are using certain “rich” classes
> - touples will be emitted via the stream named “default”
>
> Touples emitted to the ackers are emitted under the __ack_? stream
>
> On your topology page in the UI, go all the way to the bottom and click
> on “Show System Stats”. Maybe the numbers will begin to make sense.
>
> Also, you can visualize the stream using the “Show Visualization” button.
>
> From: Mark Tomko <mt...@broadinstitute.org>
> Reply-To: "user@storm.apache.org" <us...@storm.apache.org>
> Date: 2015,Tuesday, May 5 at 17:05
> To: "user@storm.apache.org" <us...@storm.apache.org>
> Subject: Tuples emitted but not transferred
>
> Hi,
>
> I have a topology that we're working on that seems to have a very long
> start-up time, even after the bolts log that they have been prepared.
> Looking at the Storm UI, I see tuples that have been "Emitted" but not
> "Transferred". The transferred count is 0 for all components, and the
> topology has an uptime now of nearly 50 minutes. The logs are free of
> exceptions or any other evidence of workers being stopped and started. Does
> anyone have any suggestions of what I should look for?
>
> Thanks,
> Mark
>
Re: Tuples emitted but not transferred
Posted by Jeff Maass <JM...@cccis.com>.
It's my understanding that the #'s cover multiple emitted streams.
If you don't name your stream, and you are using certain "rich" classes - touples will be emitted via the stream named "default"
Touples emitted to the ackers are emitted under the __ack_? stream
On your topology page in the UI, go all the way to the bottom and click on "Show System Stats". Maybe the numbers will begin to make sense.
Also, you can visualize the stream using the "Show Visualization" button.
From: Mark Tomko <mt...@broadinstitute.org>>
Reply-To: "user@storm.apache.org<ma...@storm.apache.org>" <us...@storm.apache.org>>
Date: 2015,Tuesday, May 5 at 17:05
To: "user@storm.apache.org<ma...@storm.apache.org>" <us...@storm.apache.org>>
Subject: Tuples emitted but not transferred
Hi,
I have a topology that we're working on that seems to have a very long start-up time, even after the bolts log that they have been prepared. Looking at the Storm UI, I see tuples that have been "Emitted" but not "Transferred". The transferred count is 0 for all components, and the topology has an uptime now of nearly 50 minutes. The logs are free of exceptions or any other evidence of workers being stopped and started. Does anyone have any suggestions of what I should look for?
Thanks,
Mark