We have some a Spring Boot application that we run in an Spring Test condition. This application start a job that just decrement an CountDownLatch
(with no blocking code inside or what so ever).
An test just await on this latch, to know if Quartz run the job or not.
Quartz is configured with a database, in a clustered mode, doesn't allow concurrent execution of one job. The application context is stop and recreated for each test. (ie: Quartz is stopped between each test)
Everything works fine but sometime, this test fail because the latch was never decremented. After analyse, we detected that when multiples tests are run, an instance of our job, from a previous test, is still running. So the instance job of our test is never started (because of no concurrent execution). And we got a timeout on this test.
To check this, an UUID is generated in the application context. This UUID is then printed in the job and in the test. Each time the test fail, the UUID is different in the job and in the test. It means that the Spring Application Context is not the same between the job and the test.
Quartz is stopped using a @PreDestroy
method on a bean than run quartzScheduler.shutdown(true)
(ie: Spring will indirectly call this method at the end of a test)
Our conclusion is that a Quartz job is still runing of a previous test. But we don't understand why it's still running.
- Do you have some recommandation on how to stop Quartz between unit test? (we followed this Quartz Cookbock to stop the scheduler: http://www.quartz-scheduler.org/documentation/quartz-2.x/cookbook/ShutdownScheduler.html)
- Do you have anyh explanation on why the job is still running and not stopped correctly by the test?
Regards
Aucun commentaire:
Enregistrer un commentaire