JSR-352 Java Batch: why does JobListener.afterJob() always get batch status STARTED?

Question

I'm a Java Batch newbie. I deployed a simple batch job that includes a JobListener on WebSphere Liberty 17.0.0.4 (note that I'm using IBM's JSR-352 implementation, not Spring Batch). The batch job itself runs as expected: it reads an input file, does a simple data transformation, and writes to a DB. But in the JobListener's afterJob() method for a successful execution, I see a batch status of STARTED and an exit status of null. (These are the same values I see logged in the beforeJob() method). I expected afterJob() to see a status of COMPLETED unless there were exceptions.

The execution id logged by afterJob() is the same value returned by JobOperator.start() when I kick off the job, so I know I'm getting the status of the correct job execution.

I couldn't find any examples of a JobListener that fetches a batch status, so there's probably a simple error in my JSL, or I'm fetching the batch status incorrectly. Or do I need to explicitly set a status somewhere in the implementation of the step? I'd appreciate any pointers to the correct technique for setting and getting a job execution's final batch status and exit status.

Here's the JSL:

<job ...>
    <properties>...</properties>

    <listeners>
        <listener ref="jobCompletionNotificationListener"/>
    </listeners>

    <flow id="flow1">
        <step id="step1">...</step>
    </flow>
</job>

Here's the listener's definition in batch.xml:

<ref id="jobCompletionNotificationListener"
     class="com.llbean.batch.translatepersonnames.jobs.JobCompletedListener"/>

Here's the JobListener implementation:

@Dependent
@Named("jobCompletedListener")
public class JobCompletedListener implements JobListener {
    ...
    @Inject
    private JobContext jobContext;

    @Override
    public void afterJob() {
        long executionId = jobContext.getExecutionId();
        JobExecution jobExecution = BatchRuntime.getJobOperator().getJobExecution(executionId);
        BatchStatus batchStatus = jobExecution.getBatchStatus();
        String exitStatus = jobExecution.getExitStatus();
        logger.info("afterJob(): Job id " + executionId + " batch status = " + batchStatus + 
                ", exit status = " + exitStatus);
        ...
    }
}

I tried adding <end on="*" exit-status="COMPLETED"/> to the <job> and <flow> in the JSL, but that had no effect or resulted in a status of FAILED.

score 4 · Accepted Answer · answered Jan 18 '18 at 02:26

Good question. Let me tack on a couple points to @cheng's answer.

First, to understand why we implemented it this way, consider the case where the JobListener throws an exception. Should that fail the job? In Liberty we decided it should. But if the job already had a COMPLETED status, well, that would imply that it was... completed, and shouldn't be able to fail at that point.

So afterJob() is really more like "end of job" (or you could think of it as "after job steps").

Second, one reason to even ask this question is because you want to know, in the afterJob() method, whether the job executed successfully or not.

Well, in the Liberty implementation at least (which I work on, for IBM), you can indeed see this. A previous failure will have set the BatchStatus to FAILED while a successful (this far) execution will have its status still at STARTED.

(For what it's worth, this was an area we realized could use more attention and standardization a bit late in the 1.0 spec effort, and I hope we can address more in the future.)

If it helps and you're interested, you can see the basic logic in the flow leading up to and including the WorkUnitThreadControllerImpl.endOfWorkUnit call here.

Thanks for a very thorough and helpful answer. – Mike Woinoski Jan 18 '18 at 16:31 — Mike Woinoski, Jan 18 '18 at 16:31

score 2 · Answer 2 · answered Jan 18 '18 at 01:28

2

It's because job listener's afterJob method is part of the job execution. So when you call getBatchStatus() inside afterJob() method, the job execution is still going on, and not yet completed, hence the batch status STARTED.

answered Jan 18 '18 at 01:28

cheng

1,076
6
6

Ah. Interesting. This is different than the behavior in Spring Batch's JobExecutionListener, where afterJob() sees a job execution status of COMPLETED if there were no errors. Thanks for the insight. – Mike Woinoski Jan 18 '18 at 16:08
In case of failure I see the batch status FAILED in afterJob(). It still seems distinguishable. – Queeg Oct 05 '20 at 06:39
When a job execution fails in the middle, the batch contains knows the only outcome is failure so setting the batch status to FAILED. If everything goes well till afterJob(), we still don't know if anything could go wrong at the last moment during afterJob(), hence the batch status STARTED. – cheng Oct 07 '20 at 03:19

JSR-352 Java Batch: why does JobListener.afterJob() always get batch status STARTED?

2 Answers2