Thanks for the good suggestion. I will log in the fail method and try. Since this problem happens intermittently, its difficult to reproduce.
> On Sep 27, 2015, at 8:21 PM, Madan <[email protected]> wrote: > > Yes, you are right. This should be enabled by default. Can you check from the > logs that the particular message is getting replayed. > Another sinpler way is to print the message at spout's fail method to see if > its getting invoked by the timeout. > Regards, > Madan > >> On Sep 28, 2015 08:33, "Sudha Subramanian" <[email protected]> wrote: >> Hi Madan, >> >> Are you referring to topology.enable.message.timeouts. >> >> I have not configured explicitly. I'm guessing the default value should be >> true? Is that not the case? >> >> Thanks, >> Sudha >> >> >>> On Sat, Sep 26, 2015 at 10:47 AM, Madan <[email protected]> wrote: >>> Hi, >>> Have you enable message timeout. The Spout should retry emitting the >>> message, if its not acked by the bolt. >>> Reards, >>> Madan >>> >>>> On Sep 26, 2015 19:44, "Sudha Subramanian" <[email protected]> wrote: >>>> Hi, >>>> >>>> I have a spout that emits a message on a stream. Since its on a >>>> development environment, I have a single instance of bolt to receive the >>>> message from stream and process it. The bolt is expected to ack the >>>> message to spout. >>>> >>>> It works fine majority of the times except when the bolt sometimes does >>>> not receive the emitted message from the spout. I have to kill and >>>> redeploy the topology to fix this. >>>> >>>> Can someone share some insight on what might cause this behavior? >>>> >>>> Thanks, >>>> Sudha
