I look through the code. In statustransitService, if a bundle job's coord child fails to submit, it will kill the bundle job all together. However, since kill command kills children asynchronously, checkterminalstatus will return false and the checkrunningstatus function will make the bundle job as "RUNNINGWITHERROR". Eventually, the job is marked as "DONEWITHERROR" rather than "KILLED". But, I don't how this worked in 4.0 release since this part of code looks the same. Can someone point to me what changed post 4.0?
________________________________ From: bowen zhang <[email protected]> To: "[email protected]" <[email protected]>; Rohini Palaniswamy <[email protected]>; Mona Chitnis <[email protected]> Sent: Thursday, September 18, 2014 10:34 PM Subject: Re: issue after OOZIE-1807 Right now what is in the trunk and 4.1 branch, the bundle will go into "DONEWIHTERROR" stage ________________________________ From: Mona Chitnis <[email protected]> To: Rohini Palaniswamy <[email protected]>; "[email protected]" <[email protected]> Cc: bowen zhang <[email protected]> Sent: Thursday, September 18, 2014 5:49 PM Subject: Re: issue after OOZIE-1807 bq. if a bundle with two actions - one FAILED due to coordinator submission error, other KILLED), bundle is supposed to KILLED bq. Bundle should be FAILED and not KILLED. Only when user has KILLED the bundle, should its status be KILLED. Thanks for minor correction. I was shooting for bundle will _not_ be DONEWITHERROR, which Bowen said he's observing Mona Chitnis Software Engineer, Hadoop Team Yahoo! On Thursday, September 18, 2014 5:09 PM, Rohini Palaniswamy <[email protected]> wrote: bq. Shouldn't oozie be intelligent enough to do a no-op on a killed coord job? There are options now to resume a killed coord job. If new end time was applied on other coord jobs and not applied on that one, user needs to know. bq. if a bundle with two actions - one FAILED due to coordinator submission error, other KILLED), bundle is supposed to KILLED Bundle should be FAILED and not KILLED. Only when user has KILLED the bundle, should its status be KILLED. -Rohini On Thu, Sep 18, 2014 at 4:09 PM, Purshotam Shah <[email protected]> wrote: Bowen, JIRA has explanation. Please update JIRA if you see any issue with approach. >Why is it a good idea to throw an exception if one of the coord jobs is >in "killed" state? In the BundleJobChangeXCommand, the code doesn't even >attempt to change the coord job. Shouldn't oozie be intelligent >enough >to do a no-op on a killed coord job? To let user know the list of coord jobs for which change is not applied. Puru. On 9/18/14, 2:11 PM, "bowen zhang" <[email protected]> wrote: >Hi Purshotam, >Why is it a good idea to throw an exception if one of the coord jobs is >in "killed" state? In the BundleJobChangeXCommand, the code doesn't even >attempt to change the coord job. Shouldn't oozie be intelligent enough to >do a no-op on a killed coord job? >Bowen > > > >________________________________ > From: Purshotam Shah <[email protected]> >To: "[email protected]" <[email protected]>; Mona Chitnis ><[email protected]>; bowen zhang <[email protected]> >Sent: Wednesday, September 17, 2014 6:17 PM >Subject: Re: issue after OOZIE-1807 > > >Hi Bowen, > BundleJobChangeXCommand command will get applied to bundle and coord >jobs. It will aggregate message for all killed coord jobs and throw them >as exception. >It is similar to chmod command. > >JIRA has more details. Let me know if you need any other information. > >Puru. > > > > > >On 9/17/14, 6:05 PM, "Mona Chitnis" <[email protected]> wrote: > >> >>Puru, >>Bowen just gave me a call regarding this issue. Can you answer his >>question? That'll be faster than me digging through the code. >> Mona Chitnis >>Yahoo! >> >> On Wednesday, September 17, 2014 5:51 PM, bowen zhang >><[email protected]> wrote: >> >> >> Hi guys, >> >>Purshatom, I see you checked oozie-1807 into the trunk. So, I have a >>question, why does it need to throw an exception when someone wants to >>change a bundle job where one of its coord job is in KILLED state? Due to >>the change in BundleJobChangeXCommand, this is throwing exceptions when >>trying to change a RUNNING bundle job where some of the coord jobs are >>intentionally killed by the user. >>Thanks, >>Bowen >> >> >>
