[MGNLSCH-37] Job persistence and reliability Created: 15/Jan/13  Updated: 19/May/22  Resolved: 19/May/22

Status: Closed
Project: Scheduler
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Magnolia International Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: next
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

This is perhaps a topic that needs discussions before implementation. Here's a couple of examples. Let's say I have 3 configured jobs.

  1. configured to run every 5 minutes.
  2. configured to run once a day at 4pm.
  3. one-shot, set to run on Jan 15 at 3pm.

Now, assume my server goes down on Jan 15 at 2pm for 3 hours. It comes back up at 5pm (I know this example is highly unrealistic )

Here's what I'd want to happen, ideally:

  • Job 3 gets executed once, at startup or shortly thereafter. Ideally, it logs that it was supposed to be executed earlier.
  • Job 2 gets executed at startup or shortly thereafter. Ideally, it logs that it was supposed to be executed earlier. The following days, it falls back into it's regular 4pm schedule.
  • Job 1 gets executed again, starting at 5pm, then 5.05, 5.10, etc. This already works.
    • Since it's such a short-repeat job, I wouldn't want it to be execute 36 times to compensate for the 3 hours down time.

I guess what I'm getting at is we'd need

  • a mechanism that would ensure jobs gets executed even if their scheduled time has passed. I think what we have today is a warning that "this job will never be executed", when restarting the server.
  • a way to enable/disable the above behavior, because it is not always desirable (cfr example 1)

If I recall correctly, Quartz has an API to store job states - but our current implementation uses an in-memory implementation.



 Comments   
Comment by Magnolia International [ 15/Jan/13 ]

Bingo. The interface is org.quartz.spi.JobStore and org.quartz.impl.jdbcjobstore.JobStoreSupport has, among other things a recoverJobs() which likely does what I'm trying to describe above. Unfortunately, org.quartz.impl.jdbcjobstore.JobStoreSupport is pretty much tied to JDBC and SQL. In this current version of Quartz, there doesn't seem to be an intermediate abstract class that would allow us to easily implement this over a JCR-based storage.

edit: Had a quick look at 2.1.6 and this particular point doesn't seem to have changed.

Comment by Roman Kovařík [ 19/May/22 ]

Hello,

This ticket is now marked as closed due to one of the following reasons:

  • A long period of inactivity
  • Uses an old or Beta version of an application, module, or framework that we no longer support
  • The issue is no longer reproducible or has been fixed in later versions

If you are still facing a problem or consider this issue still relevant, please feel free to re-open the ticket and we will reach out to you.

Thank you,
The Magnolia Team

Generated at Mon Feb 12 10:45:17 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.