It is not guaranteed. On Wed, Sep 2, 2015 at 11:09 AM, Sandeep Deshmukh <[email protected]> wrote:
> As I understand, I can get my task done earlier if I have that in > handleIdleTime() rathe than waiting for endWindow(). > > But can I depend solely on handleIdleTime() ? Is invocation of > handleIdleTime() guaranteed in the operator per window cycle? > > > > On Wed, Sep 2, 2015 at 7:46 AM, Pramod Immaneni <[email protected]> > wrote: > > > The time you spend in handleIdleTime could still be less than a window > > interval. If you move your processing to end window, since end window is > > called when end window is received from upstream you would delay the > > results being sent to downstream. > > > > On Wed, Sep 2, 2015 at 1:26 AM, Bhupesh Chawda <[email protected]> > > wrote: > > > > > Hi All, > > > > > > I understand that handleIdleTime() is called when the operator is > idling > > > and is intended for auxiliary processing. Also, if the operator does > not > > > have anything to do, it must block for some time to avoid busy loop. > > > What happens if my processing within handleIdleTime() exceeds the > amount > > of > > > time it would have blocked otherwise? In that case does it make a > > > difference whether the processing is done in handleIdleTime() or in > > > endWindow() call? > > > > > > To clarify the question, is this the right approach: > > > > > > handleIdleTime() > > > { > > > do some work W; > > > t = time to do work W; > > > sleep(SPIN_MILLIS - t); > > > } > > > > > > What is the right approach if t > SPIN_MILLIS? > > > > > > Thanks. > > > -- > > > Regards, > > > Bhupesh Chawda > > > > > >
