Spring Batch
  1. Spring Batch
  2. BATCH-869

End Time of a step or a job always null when read in a StepExecutionListener or a JobExecutionListener

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 1.1.2
    • Fix Version/s: 2.0.0.M3
    • Component/s: Core
    • Labels:
      None

      Description

      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));

        Activity

        Hide
        Dave Syer added a comment -

        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.

        Show
        Dave Syer added a comment - 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.
        Hide
        Robert Kasanicky added a comment -

        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?

        Show
        Robert Kasanicky added a comment - 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?
        Hide
        Laurent Bonnet added a comment -

        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"

        Show
        Laurent Bonnet added a comment - 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"
        Hide
        Robert Kasanicky added a comment -

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

        Show
        Robert Kasanicky added a comment - Changed the issue type from bug to improvement as clarified in the previous comment.
        Hide
        Dave Syer added a comment -

        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.

        Show
        Dave Syer added a comment - 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.
        Hide
        Robert Kasanicky added a comment -

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

        Show
        Robert Kasanicky added a comment - As commented above, unless there's a usecase that requires changing the behavior it makes sense to leave it as it is.

          People

          • Assignee:
            Robert Kasanicky
            Reporter:
            Laurent Bonnet
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 0.25d
              0.25d
              Remaining:
              Remaining Estimate - 0.25d
              0.25d
              Logged:
              Time Spent - Not Specified
              Not Specified