Hey Jagadish, Thank you for taking the time to review the design. I agree with moving the heartbeat into the the LocalContainerRunner instead of fitting it into the SamzaContainer. I will update the SEP with the new design changes. Also agree with the changes to the configuration and choosing suitable defaults should be good enough.
Thanks, Abhishek On Wed, Apr 26, 2017 at 3:23 PM, Jagadish Venkatraman < jagadish1...@gmail.com> wrote: > Hi Abhishek, > > Heartbeat between the AM and container has been a long awaited Samza > feature. It will go a long way in ensuring our reliability! +1 for this > SEP. > > *High level comments:* > > Currently, the only use-case for the heartbeat mechanism seems to be when > running Samza on Yarn. IMHO, it makes sense to pull the heart beat logic > into the *LocalContainerRunner* instead of baking it into the > *SamzaContainer* class. Long term, we can re-visit this when we have a > pluggable liveness detection mechanism. > > I'm thinking of a flow like this: > > There is a separate component (or a thread) inside LocalContainerRunner > that periodically polls the coordinator, and determines if it should > continue running. If the coordinator determines that the container should > not run, the *LocalContainerRunner* cleanly shuts-down the container and > the process exits with a non-zero exit status. > > The following nice properties fall out: > > - We can remove the proposed config *job.container.validator.enabled. * > - We can also remove the proposed *Killable* interface since > *SamzaContainer* (and runLoops) don't have to implement *Killable * > anymore. The life-cycle is managed by the *LocalContainerRunner* that > started it. > > *On the proposed public interfaces:* > > *job.container.validator.enabled: *I am not in favor of adding this as a > new public config. IIUC, When running Samza jobs on Yarn, we always want > the validator/heartbeats to be enabled. OTOH, when running Samza jobs in > standalone mode, we currently do not have a pluggable mechanism for > heartbeat. > > *job.container.schedule.ms <http://job.container.schedule.ms>: *It does > seem that we can pick a sensible default, and be done with it (instead of > adding a new config)? Is there a reason this needs to be configurable? > > *On proposed Killable interface: * > > Not entirely sure we need this new "*Killable"* interface (esp. given that > there's currently only one implementation - *SamzaContainer*). > > - The *LocalContainerRunner* can instead directly invoke shut-down on > the *SamzaContainer* when its heart-beat expires. The extra level of > indirection (making *SamzaContainer* to implement *Killable*) is > probably unnecessary IMHO. > > > - Since, the *LocalContainerRunner* invokes *start/run* on the > *SamzaContainer*, it seems simpler also have it invoke *shutdown* on the > *SamzaContainer. * > > *Minor Comments:* > > >> Expose a REST endpoint (eg: /isContainerValid) who's purpose is to get > requests from the Samza container periodically and respond back weather the > container is in the Job Coordinator's current list of valid containers. > > Wondering if it'd be slightly cleaner to rename this to */heartBeatRequest* > and return a *heartBeatResponse* as *CONTINUE, DIE*. The name > *isContainerValid > * and the definition of validity does seem slightly broad? > > Thanks again for taking the time to draft the SEP, and volunteering to > implement this. Nice work! > > Best, > Jagadish > > On Mon, Apr 24, 2017 at 6:42 PM, Abhishek Shivanna <abks...@gmail.com> > wrote: > > > Hi Everyone, > > > > In order to fix the issue of orphaned/leaky containers seen when the > > YARN Node Manager crashes, I have created a SEP discussing the design for > > implementing a heartbeat between the containers and the job coordinator: > > https://cwiki.apache.org/confluence/display/SAMZA/SEP- > > 3%3A+Heart-beat+mechanism+between+JobCoordinator+and+ > > all+running+containers > > > > Please take a look and provide feedback. I would also really appreciate > > help in designing a way to propagate the error up from SamzaContainer in > > order to exit the container with a non-zero exit code. > > > > Thanks, > > Abhishek > > > > > > -- > Jagadish V, > Graduate Student, > Department of Computer Science, > Stanford University >
