End Time of a step or a job always null when read in a StepExecutionListener or a JobExecutionListener [BATCH-869]

[spring-projects-issues]

Laurent Bonnet opened BATCH-869 and commented

Hello,

When using the method stepExecution.getEndTime() in a StepExecutionListener or the method JobExecution.getStartTime() in a JobExecutionListener, the End Time is null.

For the StepExecutionListener, I think it comes from the fact that all the registered listeners are called before the setEndTime() method().

The setEndTime is called on the finally block of public final void execute(StepExecution stepExecution) on line 211 and the registerd listeners are called on line 181 : exitStatus = exitStatus.and(getCompositeListener().afterStep(stepExecution));

---

Affects: 1.1.2

[spring-projects-issues]

Dave Syer commented

I think it ought to be possible to set the endTime before the last call to a listener in 2.0. In 1.1 it won't work because there might be an exception (that's why it's in a finally block.) I'll let Robert decide what to do.

[spring-projects-issues]

Robert Kasanicky commented

Isn't it expected to have null endTime before the execution is over - I'm not sure why you consider this a bug?

Listeners calls are part of the step's/job's execution, so startTime is set before calling beforeStep/Job and endTime after calling afterStep/Job. It should be technically possible to change this, but why should we want to do it?

[spring-projects-issues]

Laurent Bonnet commented

In fact I use listeners to log on a file the execution of job/steps : the start and end time.
Using log4j, I already have the time of the event (using pattern to log with the date written on each line of log)

Your point of view is that the end time has to be set after the whole execution of the job. I can understand it. I would prefer to be able to have access to the end time of a step/job in a listener

My point of view is that the afterStep listeners should be called after setting the end time. Indeed the step is finished (or being in a "post processing phase") so its end time should be set)
To sum up, my idea is that the calls of the listeners are not really a part of the step execution but more a pre/post Processing part of a whole Step.

You are right, this issue should not really be considered as a bug. We just have two point of view about what is really the end of the Job :
Maybe Dave or Lucas has an idea about it and we can discuss it

Your workflow:

Preprocessing phase :
setStartTime
CallListeners

Processing Phase

Post Processing Phase
callListeners
setEndTime

My wokflow would be:

Preprocessing phase :
setStartTime
CallListeners

Processing Phase (step or job real execution)

Post Processing Phase
setEndTime
callListeners

Thanks for your response. Be free to close this issue after a discussion with the other developpers or if you think that my point of view is not in the "framework philosophy"

[spring-projects-issues]

Robert Kasanicky commented

Changed the issue type from bug to improvement as clarified in the previous comment.

[spring-projects-issues]

Dave Syer commented

On reflection I see no immediate reason why a listener would need access to the end time. If there is a good use case we could consider changing the ordering, otherwise I suggest we leave it as it is. There is one important consideration, which isn't so much philosophical as practical - traditionally we test for whether a job is still running by looking for a null end time, so it really has to be set as late as possible to prevent anyone from drawing a conclusion from the status field in a job that appears not to be running.

[spring-projects-issues]

Robert Kasanicky commented

As commented above, unless there's a usecase that requires changing the behavior it makes sense to leave it as it is.