Re: windowing & max spout pending

In this case would you recommend keeping the bolt's parallelism at 1, to avoid having to set max.pending.spout too high? Thanks, Balazs On 09/01/2016 02:04 PM, Arun Mahadevan wrote: Hi Balazs, Yes, you are right. For event time windows, the progress (of time) is based on the timestamps of

Re: windowing & max spout pending

Hi Balazs, Yes, you are right. For event time windows, the progress (of time) is based on the timestamps of the events that arrive. So if no new events arrive, the topology can get stuck since the time does not progress. max.spout.pending > parallelism * (window length + sliding interval) is

Re: windowing & max spout pending

Hi Arun, Thanks for your promptly answer. As we have problems with our windowed topology (the average processing time keeps increasing, while the processing speed keeps dropping until hitting zero) I kept thinking about the value of max.spout.pending parameter for the case of field based

Re: windowing & max spout pending

Hi Balazs, Tuples are acked only when the window slides and the events fall out of the window. So max.spout.pending should be more than max number of tuples in window length + sliding interval. Thanks, Arun On 8/24/16, 8:33 PM, "Balázs Kossovics" wrote: >Hello,

windowing & max spout pending

Hello, I've recently hit a problem with my topology using the windowing mode when I set the TOPOLOGY_MAX_SPOUT_PENDING too low. I have a window lenght of 60 seconds and sliding interval of 1 seconds with field based timestamping. In my first tests I didn't specify