 | This articleis anorphan, as no other articleslink to it. Pleaseintroduce links to this page fromrelated articles.(May 2025) |
| JobRunr | |
|---|---|
| Original author | Ronald Dehuysser |
| Developer | Rosoco BV |
| Initial release | April 8, 2020; 5 years ago (2020-04-08) |
| Stable release | 8.1.0 / September 25, 2025; 25 days ago (2025-09-25) |
| Repository | github |
| Written in | Java |
| Operating system | Cross-platform |
| Platform | Java |
| Type | Library |
| License | Apache-2.0 |
| Website | jobrunr |
JobRunr is an open-source job-scheduling library for theJava platform that lets developers enqueue, delay or run recurring background tasks across one or manyJVMs while persisting state in a relational orNoSQL data store.
First released in April 2020 by Belgian developer Ronald Dehuysser, the project has become a popular alternative toQuartz Scheduler andSpring Batch for cloud-native workloads owing to its lightweight API, seamless integration with other frameworks (such asSpring orQuarkus) and embedded dashboard.[1] Dehuysser unveiled the initial public version of JobRunr onGitHub during the earlyCOVID-19 lockdowns, positioning it as "Hangfire for Java." The library compiled cleanly on the JDK 17 early-access builds by July 2021, signalling an emphasis onforward compatibility and participation in Oracle's Quality Outreach programme.[2]
Version 4.0 (September 2021) marked the first major milestone. InfoQ reported that the release added a job-analysis performance mode, static-method lambda support and optional byte-code caching, together with first-class starters forSpring Boot,Quarkus andMicronaut.[3]
Six months later, JobRunr 5.0 shipped with default-retry configuration, cron extensions supporting "last-day" semantics and an officially supported Spring Native starter. The update also introducedDuration-based recurrent scheduling and optional MDC propagation in the dashboard logs.[4]
JobRunr 6.0 (February 2023) focused on developer ergonomics: a fluentJobBuilder API, arbitrary job labels, an opt-in Micrometer metrics bridge and performance tweaks that halved enqueue latency under load test.[1]
With JobRunr 7.0 (May 2024) the project embraced JDK 21'svirtual threads, automatically switching the worker pool when the host JVM supports it, and replaced random UUIDs with time-based UUIDs to reduce database-index fragmentation. The release also moved the@Recurring annotation into the core module and introduced anInMemoryStorageProvider for rapid CI pipelines.[5]
JobRunr targets common background-processing tasks, sending email batches, PDF generation, ETL pipelines or asynchronous REST callbacks, without requiring a separate service bus. Jobs are expressed as ordinary Java 8 lambdas or method references; at run time the library inspects the byte-code withASM, serialises the invocation metadata to JSON and stores it via a pluggable StorageProvider (RDBMS,MongoDB,Redis,Elasticsearch or in-memory).[6]
Key functional highlights include:
enqueue,schedule,scheduleRecurrently) and a more expressive fluent builder added in v 6.0 for complex triggers.[1]BackgroundJobServer instances poll the same table or collection.[1]Internally, JobRunr follows a storage-centric architecture. During scheduling the library captures the target lambda or method, its arguments and metadata; serialises this envelope as JSON and inserts it into ajob table (or equivalent collection); commits using optimistic locking so that exactly one caller wins in a cluster.[1] Worker nodes,BackgroundJobServers, poll the storage at a configurable interval (200 ms in fast in-memory mode; 5–15 s in production). When a server claims a job it deserialises the payload, resolves any Spring or Micronaut beans, executes user code in a worker thread, virtual or platform, and then updates the job state atomically. Failed executions are automatically re-queued with exponential back-off up to a default of ten retries (tunable or overridable per job).[4]
Because the storage layer is abstracted behind StorageProvider, JobRunr can run on traditional RDBMS systems such asPostgreSQL,MariaDB andOracle and on NoSQL engines like MongoDB. Each provider supplies SQL or driver-specific concurrency primitives; for example, v 7.0 introducedSELECT … FOR UPDATE SKIP LOCKED for PostgreSQL and MySQL to minimise lock contention.[5]
The dashboard and REST endpoints are packaged so that they do not require a separate service; they share the same transaction scope as job execution, guaranteeing eventually consistent metrics. A commercial "JobRunr Pro" edition layers priority queues, batch chaining and forthcoming carbon-aware scheduling on top of the open-source core.[7]