Skip to main content

[jsr352-public] Re: Do we need another BatchStatus transition (mark jobs as FAILED)?

  • From: Scott Kurz < >
  • To:
  • Subject: [jsr352-public] Re: Do we need another BatchStatus transition (mark jobs as FAILED)?
  • Date: Mon, 28 Oct 2013 10:50:08 -0400


Right..the impl would only be required to document as it sees fit...

I'm glad we had this discussion since saying the runtime would "mark
FAILED" would have been too strong.

Assuming you're still in agreement, I'll add this to the change list...

Thanks,
------------------------------------------------------
Scott Kurz
WebSphere Batch / Compute Grid Development
T/L 295-5649;
External Phone 845-435-5649

--------------------------------------------------------



From:   Michael Minella 
< >
To:     
" "
 
< >,
Date:   10/28/2013 10:45 AM
Subject:        [jsr352-public] Re: Do we need another BatchStatus transition
            (mark jobs as FAILED)?



Would the impl be required to provide something more than documentation?
Right now, SB just states that the user needs to address the state in the
job repository by hand and we'd like to keep it that way unless the JSR has
a portable way of implementing that.

Thanks,
Michael Minella

http://www.michaelminella.com


On Mon, Oct 28, 2013 at 9:38 AM, Scott Kurz 
< >
 wrote:
  Michael,

  Thanks for giving this some thought and relaying that discussion.

  So note, I'm not suggesting any rules or standards defining how a job
  such as this gets marked FAILED by the implementation.
  I was simply suggesting that, say in Sec 8.7, we include a sentence or
  two acknowledging this transition getting performed by SOMEONE.

  Maybe saying the runtime does it was too strong...

  How about:

  "In the case of a job that ...... e..g hung JVM.... etc....
    It is expected that an implementation provides some
  implementation-specific mechanism for transitioning BatchStatus to FAILED
  state, so that it can be restarted.  This mechanism can be executed
  automatically by the implementation or via an implementation-defined
  manual operation."

  What's the point of saying that?   I think simply that the spec is
  clearly trying to define a complete state transition flowchart.... and so
  this obvious gap should be closed, even if the details are implementation
  specific.




  ------------------------------------------------------
  Scott Kurz
  WebSphere Batch / Compute Grid Development
  T/L 295-5649;
  External Phone 845-435-5649
  

  --------------------------------------------------------

  Inactive hide details for Michael Minella ---10/28/2013 10:26:51
  AM---Spring Batch has taken the approach that this is not someMichael
  Minella ---10/28/2013 10:26:51 AM---Spring Batch has taken the approach
  that this is not something the framework should support.  We act

  From: Michael Minella 
< >
  To: 
" "
 
< >,
  Date: 10/28/2013 10:26 AM
  Subject: [jsr352-public] Re: Do we need another BatchStatus transition
  (mark jobs as FAILED)?




  Spring Batch has taken the approach that this is not something the
  framework should support.  We actually had a bit of a spirited debate on
  this at this year's SpringOne in one of the batch talks.  Our stance is
  that in this scenario, it is almost always a human decision that is
  required to determine that this update is required.  In the example you
  provide (a JVM dies for some reason), how would the job or other JVM know
  what happened?  In the end, it would typically take human investigation
  and then action.  The furthest I would suggest we go (if at all) would be
  providing a method on the JobOperator to set a Job/Step to a given status
  programatically.  This would prevent the need to manually update the
  underlying job repository impl (database tables in most cases) by hand.

  Michael

  Thanks,
  Michael Minella
  

  http://www.michaelminella.com


  On Fri, Oct 25, 2013 at 9:47 PM, Scott Kurz 
< >
 wrote:
        I don't remember this issue being raised up until now (maybe it was
        in the EG)...

        Say a job is running along and someone kills the JVM or it hits
        OOM.    Can't the implementation determine somehow that jobs like
        this should be moved into FAILED state (BatchStatus)?

        I don't think the spec needs to specify how this happens... but it
        seems to try to completely cover all state transitions, and it
        specifically disallows restart of an already-STARTED job (in Sec.
        10.8).

        So I think it should say something allowing this "mark FAILED"
        transition to occur in an impl-specific way.

        Thoughts?
        ------------------------------------------------------
        Scott Kurz
        WebSphere Batch / Compute Grid Development
        T/L 295-5649;
        External Phone 845-435-5649
        

        --------------------------------------------------------





GIF image



[jsr352-public] Do we need another BatchStatus transition (mark jobs as FAILED)?

Scott Kurz 10/26/2013

[jsr352-public] Re: Do we need another BatchStatus transition (mark jobs as FAILED)?

Michael Minella 10/28/2013

[jsr352-public] Re: Do we need another BatchStatus transition (mark jobs as FAILED)?

Scott Kurz 10/28/2013

[jsr352-public] Re: Do we need another BatchStatus transition (mark jobs as FAILED)?

Michael Minella 10/28/2013

[jsr352-public] Re: Do we need another BatchStatus transition (mark jobs as FAILED)?

Scott Kurz 10/28/2013

[jsr352-public] Re: Do we need another BatchStatus transition (mark jobs as FAILED)?

Michael Minella 10/28/2013

[jsr352-public] Re: Do we need another BatchStatus transition (mark jobs as FAILED)?

Cheng Fang 10/28/2013
 
 
Close
loading
Please Confirm
Close