[#BATCH-181] When trying to re-run a Job that already executed successfully the JobExecutorFacade returns ExitStatus.FAILED

Spring Batch

When trying to re-run a Job that already executed successfully the JobExecutorFacade returns ExitStatus.FAILED

Created: 22/Oct/07 07:21 PM Updated: 07/Aug/08 10:06 AM

Component/s:

None

Affects Version/s:

1.0-m2

Fix Version/s:

1.0-m3

Security Level:

Public (Public Issues)

Time Tracking:

Not Specified

Description

« Hide

The DefaultJobExecutor sets the status to ExitStatus.FAILED when the run() method starts, but if the steps do not execute (i.e. they are all finished) then FAILED is returned, insted of FINISHED.

Notice that some other odd (or rather unexpected) behaviours also occur when an exception is thrown (no exit status is returned but rather an exception) or if the Job is Stopped (again, an exception is thrown).

I also can't check the status of a Job with the JobExecutorFacade so I can't really ask the status of the Job before executing.

Regards
Andres B.

All

Comments

Work Log

Change History

FishEye

Builds

Sort Order:

[ Permlink | « Hide ]

Lucas Ward added a comment - 22/Oct/07 11:31 PM

This looks like a duplicate of ~~BATCH-127~~. We could quickly fix by having the Repository throw an exception, but as in 127, this could perhaps be configurable. (Although if it was, I'm not sure whether restartable would serve any purpose anymore.)

[ Permlink | « Hide ]

Dave Syer added a comment - 02/Nov/07 04:40 AM

I agree that FAILED is wrong. We could throw an exception if a JobExecution leads to no processing because the Job is already complete (JobAlreadyCompleteException?). The alternative would be an additional ExitStatus (ALREADY_COMPLETE?). Suggestions welcome.

Whether or not you get an ExitStatus or an exception should depend on where the exception was thrown. For instance NoSuchJobConfigurationException is a checked exception that is thrown by the facade. Can you (in a separate JIRA task please) describe the unexpected behaviour in a bit more detail with an example? In what circumstances does a call to stop(JobIdentifier) lead to an exception being thrown?

Checking the status of a JobExecution is not possible with the current facade. But you can at least track the status in the database manually (just not with the facade) - this is not ideal, hance ~~BATCH-159~~. But it isn't at all easy to implement a solution - I just need some more time. Please switch to ~~BATCH-159~~ to discuss this one if you need more detail.

[ Permlink | « Hide ]

Dave Syer added a comment - 09/Nov/07 08:59 AM

~~BATCH-159~~ is now complete to the point where this issue is mostly redundant. There have also been changes so that in this scenario a job execution comes back with an exit decription that shows that no processing was done. A show of hands at the recent IJTC conference showed that people preferred to have a new exit code - this was introduced with code NOOP.

[ Permlink | « Hide ]

Dave Syer added a comment - 07/Aug/08 10:06 AM

Assume closed as resolved and released