That is what it is looking like to me. The task is submitted GenericNode#checkpoint line 504, then at the end of the GenericNode#checkpoint line 531 checkpointed is called. I am likely missing something, just would like to know what :)
Tim On Tue, Nov 10, 2015 at 10:51 AM, Pramod Immaneni <[email protected]> wrote: > Tim, > > Are you suggesting that checkpointed is called before the checkpoint is > completely persisted in the storage. > > Thanks > > On Tue, Nov 10, 2015 at 10:49 AM, Timothy Farkas <[email protected]> > wrote: > > > Chetan, > > > > I do not see the process of reporting the checkpoint to stram, receiving > > the ack, and then calling checkpointed. The logic I'm seeing in > GenericNode > > line 484 is that the checkpoint method is called, it spawns another > thread > > that writes to hdfs, and then checkpointed is immediately called > > afterwards. I am missing something, can you give me some pointers so > that I > > can better understand the flow? > > > > Tim > > > > On Tue, Nov 10, 2015 at 10:33 AM, Munagala Ramanath <[email protected] > > > > wrote: > > > > > Chetan's answer provides a good explanation as well as clarifying that > > > the difference can be more than 1. > > > > > > Since checkpointing (i.e. "commit notification" as Thomas refers to > > > it) is asynchronous, I'm curious > > > about whether the window ids in the checkpointed call are guaranteed > > > to be sequential or if they could > > > be out of order, i.e. can the checkpointed call see window id 101 > > > before it sees 100 ? > > > > > > Ram > > > > > > On Tue, Nov 10, 2015 at 10:27 AM, Bhupesh Chawda > > > <[email protected]> wrote: > > > > Hi Tim, > > > > Thanks for the detailed explanation. > > > > I understand that the sequence would be > > > > beginWindow (x) -> endWindow (x) -> checkpointed (x) -> beginWindow > > > > (x+1) > > > > > > > > However when I try to print out the window ids in beginWindow, > > endWindow > > > > and checkpointed calls, I see x and x-1 respectively. > > > > I.e. If the window just before checkpoint is 100, I see that the > > > > checkpointed call had window id 99. > > > > > > > > Note: This is observed in the local mode of Apex. > > > > > > > > Thanks > > > > -Bhupesh > > > > On 10-Nov-2015 11:25 pm, "Timothy Farkas" <[email protected]> > wrote: > > > > > > > >> Hi Bhupesh, > > > >> > > > >> The sequencing of checkpoint called in relation to beginWindow and > > > >> endWindow depends on how your APPLICATION_WINDOW_COUNT and > > > >> CHECKPOINT_WINDOW_COUNT are configured. If the two WINDOW_COUNTs are > > not > > > >> configured to be the same then it is possible that checkpointed is > > > called > > > >> within an application window. So the sequence of events would be > this: > > > >> > > > >> beginWindow -> checkpointed -> endWindow > > > >> > > > >> If the APPLICATION_WINDOW_COUNT and CHECKPOINT_WINDOW_COUNT are the > > same > > > >> (default). Then the sequence of calls would be this: > > > >> > > > >> beginWindow (100) -> endWindow (100) -> checkpointed (100) -> > > > beginWindow > > > >> (101) > > > >> > > > >> The numbers in the sequence represent possible streaming window Ids > > that > > > >> each call would be associated with. > > > >> > > > >> The StateMachine which calls these callbacks for non-input operators > > is > > > in > > > >> GenericNode.java. > > > >> > > > >> Tim > > > >> > > > >> On Tue, Nov 10, 2015 at 3:36 AM, Bhupesh Chawda < > > > [email protected]> > > > >> wrote: > > > >> > > > >> > Hi Chetan / Community, > > > >> > > > > >> > Can someone please elaborate on why the window id supplied to > > > >> > CheckpointListener and the Operator would differ. > > > >> > I tried looking at the window ids of checkpointed() and the > > > beginWindow() > > > >> > calls and they differ by 1. Don't know why this should be the > case. > > > >> > > > > >> > Thanks. > > > >> > -Bhupesh > > > >> > > > > >> > On Thu, Sep 17, 2015 at 5:56 AM, Chetan Narsude < > > > [email protected]> > > > >> > wrote: > > > >> > > > > >> > > Short answer is yes. > > > >> > > > > > >> > > All the control tuples are scheduled to be delivered outside of > > the > > > >> > window. > > > >> > > As checkpointed callback is triggered because of CHECKPOINT > > control > > > >> > tuple, > > > >> > > it will happen after endWindow and before the next beginWindow. > > > >> > > > > > >> > > The windowId supplied to CheckpointListener and the one provided > > to > > > >> > > Operator need not match even though the sequence is defined. So > I > > am > > > >> > > curious how you intend to use this knowledge. > > > >> > > > > > >> > > -- > > > >> > > Chetan > > > >> > > > > > >> > > > > > >> > > On Tue, Sep 15, 2015 at 8:31 AM, Thomas Weise < > > > [email protected]> > > > >> > > wrote: > > > >> > > > > > >> > > > It has not changed the operator execution model. State > > > serialization > > > >> is > > > >> > > > still synchronous, write to HDFS is taken out of the operator > > > thread. > > > >> > > > > > > >> > > > On Tue, Sep 15, 2015 at 8:18 AM, Amol Kekre < > > [email protected] > > > > > > > >> > > wrote: > > > >> > > > > > > >> > > > > > > > >> > > > > Sent too soon. Has asynchronous checkpointing changed this? > > > >> > > > > > > > >> > > > > Amol > > > >> > > > > > > > >> > > > > Sent from my iPhone > > > >> > > > > > > > >> > > > > > On Sep 15, 2015, at 12:38 AM, Bhupesh Chawda < > > > >> > > [email protected]> > > > >> > > > > wrote: > > > >> > > > > > > > > >> > > > > > Hi All, > > > >> > > > > > > > > >> > > > > > Is it safe to assume that the checkpointed() and the > > > >> beginWindow() > > > >> > > > calls > > > >> > > > > > are sequenced? > > > >> > > > > > In other words, are these calls part of the same thread > and > > > may > > > >> not > > > >> > > run > > > >> > > > > in > > > >> > > > > > parallel? > > > >> > > > > > > > > >> > > > > > Thanks. > > > >> > > > > > > > > >> > > > > > -- > > > >> > > > > > -Bhupesh > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > >
