Exception on closing ItemStream doesn't change StepExecution.ExitStatus

amy

Hi,

I'm using ItemStream.close() to write out the summarised results of a Step, but it seems that if an Exception occurs it is logged but ignored.

This means that the Step and Job are marked as COMPLETE when I think they should be marked as FAILED.

It seems that the StepExecution is written to the JobRepository before the ItemStream is closed.

The FlatFileItemWriter appears to use this mechanism when writing the footer, and I think it fails in an similar manner. Have I mis-used the ItemStream?

Thanks in advance,

Stu.Code:
// AbstractStep.execute

finally {
// update ExitStatus // write to JobRepository // close ExecutionContext (TaskletStep.close(.) calls ItemStream.close())

}Someone else noticed this recently but I don't remember seeing a ticket in JIRA.  This is more of a feature than a bug - you aren't supposed to do business processing in ItemStream.close(), just clean up and free resources.  As a workaround I'm sure you could find another place to put your logic that keeps it in the try/catch block which governs the Step status (e.g. implement StepExecutionListener).

Thanks - I've raised BATCH-1697 to track this, hopefully I'll be able to propose a patch.

Actually, on review it seems that a similar issue affects the StepExcutionListener interface.

Unfortunately, an Exception from the StepExecutionListener is only logged; an ItemStream Exception is also added to the FailureExceptions of the Step.

This seems odd; should both the StepExecutionListener and the ItemStream be complete before updating the JobRepository?

There is a general policy in Step implementations that listeners must not throw exceptions (and if they do they might be ignored or cause the Step to fail in an UNKNOWN state).  There are just too many paths to failure to try and cover them all with a controlled outcome.  The log message should make that clear.