JobRunr 5.0.0 Delivers Improved Framework Support

Just over six months after the release of JobRunr 4.0, Ronald Dehuysser, founder and main developer of JobRunr, has introduced JobRunr 5.0 to deliver improved support for Spring, Quarkus, and Micronaut by providing a Spring Native implementation, configuration for the default number of retries, database type selection, and transaction support. Now jobs may be scheduled based on an interval and cron expressions support the last day of the week and last day of the month.

JobRunr, an open-source JVM job scheduling tool that is free for commercial use, enables background processing in Java using persistent storage and supports distributed solutions. The paid professional version additionally offers queues, batches, and job chaining. A generic Java library is available as well as specific solutions for Spring Boot, Micronaut, and Quarkus.

A SQL, NoSQL or InMemory data source should be configured in order to use JobRunr. Various options are available after the configuration in order to run background tasks:

BackgroundJob.enqueue(() -> 
    System.out.println("Fire and forget, executed once."));
BackgroundJob.schedule(now().plusMinutes(1), () -> 
    System.out.println("Scheduled job, executed once"));
BackgroundJob.scheduleRecurrently(Cron.every30seconds(), () -> 
    System.out.println("Recurring job, executed every 30 seconds"));
BackgroundJob.enqueue(() -> jobRunrService.annotatedJob("retry"));

The last statement uses a method with the @Job annotation in order to retry the job in case of exceptions:

@Job(name = "Example retry job", retries = 1)
public void annotatedJob(String variable) throws Exception {
	System.out.println("Annotated job " + variable);
	throw new Exception("Trigger retry");
}

The example produces the following output, where the last line is repeated indefinitely:

Recurring job, executed every 30 seconds
Fire and forget, executed once.
Annotated job retry
java.lang.Exception: Trigger retry
…
Annotated job retry
java.lang.Exception: Trigger retry
…
Recurring job, executed every 30 seconds
Scheduled job, executed once
Recurring job, executed every 30 seconds

This new version supports Spring Native with the jobrunr-spring-boot-native dependency in order to build and run applications with GraalVM.

Scheduling jobs is now also possible by using an instance of the Duration class as a repeating interval:

BackgroundJob.scheduleRecurrently("recurring-job", Duration.ofSeconds(10), 
    () -> System.out.println("Recurring job"));

Changing the recurring jobs to support intervals is a breaking change; all recurring and scheduled jobs should be removed before upgrading to JobRunr 5.0.

JobRunr has an optional web-based dashboard which, among others, displays the logging. The Mapped Diagnostic Context (MDC) of SLF4J allows the usage of MDC variables inside logging such as using the request correlationId:

@Job(name = "Example retry job %X{request.correlationId}", retries = 1)

Cron expression support to schedule jobs on the last day of the week and the last day of the month is now possible by placing an "L" in the day of week or day of month fields.

Specifying the default number of retries is now possible for Spring Boot, Quarkus and Micronaut:

# Spring Boot
org.jobrunr.jobs.default-number-of-retries=42

# Quarkus
quarkus.jobs.default-number-of-retries=42

# Micronaut
jobrunr:
  jobs:
	default-number-of-retries:42

When multiple databases are available for Spring Boot, Micronaut or Quarkus, it's possible to configure the JobRunr database by specifying the database type, for example sql:

# Spring Boot
org.jobrunr.database.type=sql 

# Quarkus
quarkus.jobrunr.database.type=sql

# Micronaut:
jobrunr:
  database:
	type:sql

JobRunr's fluent API now supports Micrometer metrics:

JobRunr.configure()
    .useMicroMeter(new JobRunrMicroMeterIntegration(meterRegistry));

With this version, the dashboard has noIndex and noFollow meta tags so that publicly available dashboards on the internet are no longer indexed by Google.

Recurring jobs are now cached and reloaded once the number of jobs changes. This improves performance since the jobs are no longer reloaded from the StorageProvider interface whenever JobRunr checks for new work.

Breaking changes in this release will require an update of ElasticSearch and all JobRunr-related project dependencies.

The following features are only available for the JobRunr Pro edition.

• Transactions created by Spring Boot Starter or the Micronaut Integration are used by JobRunr Pro.
• Instant processing of jobs is now possible as the BackgroundJobServer no longer requires a pollInterval of at least 5 seconds. Spring, Micronaut and Quarkus beans implementing JobClientFilter or JobServerFilter are automatically registered in JobRunr as Job Filters, enabling developers to extend the existing features of JobRunr.
• With ServerTags, used to specify on which server a Job can run, it’s now possible to schedule a job only on the server which scheduled it: @Job(runOnServerWithTag = "%CURRENT_SERVER")
• The JobRunr Pro Dashboard now allows to requeue or delete all failed jobs at once.
• The JobScheduler class can now query for Job Results from the database.

When asked, in September 2021, about what the Java community should know about JobRunr, Dehuysser told InfoQ:

Dehuysser: I would like to highlight three things:

1. JobRunr does some magic with ASM (which is also used by Spring, Hibernate and a lot of other frameworks) to analyze the job lambda. By using ASM, I really learned a lot about the JVM bytecode, which is not as difficult as I imagined.
2. As JobRunr performs bytecode analysis, it also participates in the Oracle Quality Outreach program. This means JobRunr is tested against upcoming releases of the JVM. This helps me to make sure that it will continue working on newer Java releases and also helps the Java community as bugs in the JVM itself are caught earlier.
3. For users who need support or extra features, there is also JobRunr Pro. It builds on top of JobRunr and adds extra features like queues with different priorities (high priority jobs get processed before low priority jobs), job chaining, atomic batches and a better dashboard which adds search capabilities.

And, for any license sold, some new trees are planted as 5% of the revenue goes to teamtrees.

Further details on the complete list of changes are available on the JobRunr 5.0 blog post.