JobDetail orphaned after deleting only Trigger referencing it

[ytsejammer]

Hello Michael,

We have continued our use of the MongoDb data store and we have found another behavior that we are not quite sure is the right one. Basically, when you schedule a Trigger (specifically, we are using Cron Triggers) along with a JobDetail and after the Trigger starts the Job execution, the trigger is removed from the quartz_triggers collection as expected. However, the Job detail remains in the corresponding collection, quartz_jobs.

We have made sure that the job detail is non-durable and that there are no other Triggers with a reference to a specific JobDetail. More precisely, our implementation has a one-to-one relationship between Triggers and Jobs. We have tracked down the conflict to the MongoDBJobStore#removeTrigger(TriggerKey triggerKey) method. Our current understanding of the problem is as follows:

• removeTrigger is invoked
• load the Trigger corresponding to the triggerKey passed
• if the trigger has a field with a reference to a JobDetail (it does), load the corresponding JobDetail (https://github.com/michaelklishin/quartz-mongodb/blob/master/src/main/java/com/novemberain/quartz/mongodb/MongoDBJobStore.java#L207)
• If the JobDetail loaded does not have a JOB_DURABILITY field or it's set to false, load the collection of triggers pointing to it (https://github.com/michaelklishin/quartz-mongodb/blob/master/src/main/java/com/novemberain/quartz/mongodb/MongoDBJobStore.java#L207). This, of course, still includes the trigger that originated this very call to removeTrigger.
• The list of triggers is not null, but it contains one element (count != 0), therefore the step to delete the JobDetail (https://github.com/michaelklishin/quartz-mongodb/blob/master/src/main/java/com/novemberain/quartz/mongodb/MongoDBJobStore.java#L207) is skipped altogether.
• Proceed to remove the trigger that was originally attempted to remove with this call to removeTrigger (https://github.com/michaelklishin/quartz-mongodb/blob/master/src/main/java/com/novemberain/quartz/mongodb/MongoDBJobStore.java#L207)

Is there any other logic that we are missing that might be taking care of this orphaned job record (document) in the quartz_jobs collection? Any hints are appreciated. :)

Thanks for your reply,

P.S. We noticed that the storeJobInMongo method (https://github.com/michaelklishin/quartz-mongodb/blob/master/src/main/java/com/novemberain/quartz/mongodb/MongoDBJobStore.java#L905) is not putting the JOB_DURABILITY field in the job BasicDBObject instance. Although this does not affect our above points, we found that it might cause an unexpected behavior in other situations.

[vladvoic]

I remember writing this code so I naturally took a look to see what happened as this worked when I implemented it.

This change here broke the behavior [0]. I think a unit test is necessary here.

[0] https://github.com/michaelklishin/quartz-mongodb/commit/19c2634afd1d343d099729f39421c629d4f97bb9

[michaelklishin]

Thanks for the detailed investigation folks. I'd need to compare JDBC-based and RAM-only implementations more closely as they seem to have slight differences and our test suite needs more sophisticated examples.

[michaelklishin]

I corrected both points in master, please give it a try (I can release a new beta if that would be more convenient). Now to come up with a unit test.