Announcement Announcement Module
No announcement yet.
Help required identifying the causes of JobInterruptedException Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Help required identifying the causes of JobInterruptedException

    We're seeing many partitioned steps failing with an "EXIT_MESSAGE" of JobInterruptedException.

    There are definitely exceptions coming from readers, processors and writers for a whole host of reasons but I do not understand why they would lead to Spring Batch then stopping the step with a JobInterruptedException.

    Before I start uploading lots of code and xml I'd like to get a better understanding of the philosophy behind the JobInterruptedException, what it represents and the states that makes it occur.

    With that information I may be able to more easily track down the root cause myself.

    If anyone has any useful insights they would be much appreciated.


  • #2
    A JobInterruptedException indicates that you sent a signal to a Job to stop processing. Out of the box there are three possible causes: you set the terminateOnly() flag on the StepExecution, or the status of the JobExecution to STOPPING, or the thread that was executing your step was interrupted (Thread.interrupt()). It's hard to know from the information you supply which of these is more likely, but since it involves a partitioned step I'd guess the last (Thread.interrupt()). That can can happen, for instance, if you launch the job in a background thread and don't wait for it to finish before the thread pool is shut down (e.g. when the ApplicationContext closes).


    • #3
      Dave, thanks for your response.

      After a spot of debugging I found that deadlocks were causing the transaction to fail in AbstractPlatformTransactionManager.processCommit.

      This leads to a transaction status of 'TransactionSynchronization.STATUS_UNKNOWN' which Spring batch then translates to a JobInterruptedException.

      I'm not sure yet why this is the transactional behaviour when a deadlock is encountered but I guess that question is for a different forum.

      Thanks again,