Sure, Let me know what happens Regards, Madan On Sep 28, 2015 10:45, "Sudha" <[email protected]> wrote:
> 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 >>>> >>> >>
