Bug 4110 - Clarify at what point the JobOperator.stop returns (and maybe start/restart?)
Clarify at what point the JobOperator.stop returns (and maybe start/restart?)
Product: jbatch
Classification: Unclassified
Component: source
All All
: P5 minor
: ---
Assigned To: cvignola
Depends on:
  Show dependency treegraph
Reported: 2012-09-07 13:44 UTC by ScottKurz
Modified: 2013-01-16 23:04 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description ScottKurz 2012-09-07 13:44:22 UTC
Reading into the return types of stop/start/restart... it's clear that you expect them to work asynchronously to the actual stop/start/restart.

E.g. if you expected stop() to block until the job was stopped, you'd have some kind of return code indicator.   And start/restart are clearly supposed to return once the execution id has been assigned.

So I'm calling this minor but I think it would help to spell it out a bit more...  knowing that a method is asynchronous in any manner is one of the most important things to know about it.   I think it could even be in the Javadoc as you've started describing it there..
Comment 1 cvignola 2012-10-05 21:11:11 UTC
I will clarify in the spec.  I will start here:

JobOperator.stop is a non-blocking operation.  It returns after the stop directive has been queued up for processing by the batch container.  JobOperator.stop does not indicate whether or not the job has actually stopped. That is known only by querying job status.

The processing of the queued element should start an asynchronous unit of execution (e.g. executor thread) that carries out the stop request by invoking the batchlet's stop method and then by interrupting the thread.
Comment 2 cvignola 2013-01-16 17:14:53 UTC
This is clearly documented in 7.8.10 JobOperator.