v6.1.1

New features

None

Bugfixes

• #714: Bugfix regarding migration Recurring Jobs from v5 to v6 for labels (only in OSS version)
• #711: Bugfix regarding migration from Jobs from v5 to v6 for labels when using Yasson

v6.1.0

🎉 We're happy to announce the release of JobRunr and JobRunr Pro 6.1.0 🎉.

This release includes an important bugfix that surfaced during our internal load testing that exists already since JobRunr 1.0. In some cases, JobRunr does not close an InputStream resulting in a FileSystemException because of too many open files. See GitHub issue 707 for more info.

Another big improvement is that you now have more options in the JobServerFilter, allowing you to take custom actions when a Job failed and all the retries are exhausted.

Improvements

• GitHub issue 639 : You can now change the Recurring Job schedule from the dashboard
• GitHub issue 571 : Liquibase and Flyway support
• GitHub issue 687 : Allow to have different user for SQL migrations then at runtime
• GitHub issue 671: Allow easier mocking of JobContext: you can now call MockJobContext.setUpJobContext(jobContext) which helps to test Jobs using the JobRequest & JobRequestHandler
• GitHub issue 690: Quarkus extension support for AWS DocumentDB: JobRunr now also supports AWS DocumentDB out of the box
• GitHub issue 696: The functionality of the JobServerFilter has improved a lot. You can now have custom logic that will be executed when a job succeeds, fails or fails after all retries are exhausted.

Bugfixes

• GitHub issue 50 : Performance improvements related to batch jobs
• GitHub issue 27 : Performance improvements related to batch jobs
• GitHub issue 104 : On intermittent database problems, JobRunr stops processing
• The dashboard running in Spring did not support context path
• GitHub issue 707: Classpath InputStream not closed when analysing a lambda
• GitHub issue 691: JobContext as parameter for Recurring Job not working for Quarkus (we had to work around a bug in Quarkus)
• GitHub issue 694: Primitive Parameters used in lambda are cached in some cases.

v6.0.0

JobRunr-Pro v6.0.0

🥳 We're happy to announce the 6.0.0 release of JobRunr! 🥳

New features in JobRunr

This includes a lot of new functionality and improvements:

• Job Builders: You can now create jobs using the JobBuilder and RecurringJobBuilder which allows you to configure all the aspects of a Job via this builder instead of the @Job annotation. This means you can now have one api to create jobs with different settings (including name and amount of retries).
  An example on how to use the JobBuilder:

jobScheduler.create(aJob()
    .withName("My Enqueued Job")
    .withAmountOfRetries(3)
    .withDetails(() -> service.doWork()));

Off course, you can also schedule jobs:

jobScheduler.create(aJob()
    .withName("My Scheduled Job")
    .scheduleAt(Instant.parse(scheduleAt))
    .withDetails(() -> service.doWork()));

And this also works for JobRequests:

jobRequestScheduler.create(aJob()
    .withName("Scan " + file.getName() + " for viruses")
    .scheduleIn(Duration.ofMinutes(10))
    .withJobRequest(new ScanFileForVirusJobRequest(file.getAbsolutePath())));

• Job Labels: Support for Job Labels! From now on, you can tag jobs with labels (think of a tenant / customer id / ... ). These labels will be visible in the dashboard. Oh, and in the pro version, you can search for labels in the dashboard!
  A label can be added both via the existing @Job annotation or the new JobBuilder:

@Job(name="My Job", labels={"fast-running-job", "tenant-%0"})
void myFastJob(String tenandId) {
 // your business logic
}

jobScheduler.create(aJob()
    .withName("My Enqueued Job")
    .withLabels("fast-running-job", "tenant-" + tenantId)
    .withDetails(() -> service.doWork()));

• Server name visible in dashboard: from now on, the server name is also visible in the dashboard. Under the tab BackgroundJobServers, you will see the host name of each server. This is also configurable and can be controlled via Spring Boot / Micronaut / Quarkus properties
• Spring Boot 3 AOT support: As of JobRunr 6, we generate new artifacts for spring, one for projects on Spring Boot 3 and one for projects still on Spring Boot 2:

<dependency>
    <groupId>org.jobrunr</groupId>
    <artifactId>jobrunr-spring-boot-2-starter</artifactId>
    <version>${jobrunr.version}</version>
</dependency>

<dependency>
    <groupId>org.jobrunr</groupId>
    <artifactId>jobrunr-spring-boot-3-starter</artifactId>
    <version>${jobrunr.version}</version>
</dependency>

The jobrunr-spring-boot-3-starter will automatically participate in the ahead-of-time processing if you're using a JobRequest.

• MDC Support during success and failure of a job: when a Job fails or succeeds, this was already automatically logged. But, you now also have access to all your MDC variables when the success or failure message is logged. Two extra MDC variables have been added: jobrunr.jobId and jobrunr.jobName.
• Performance improvements:
  • on job enqueue: whenever a Job is created, a notification is sent so the dashboard figures can be updated. As this is quite a heavy database aggregation, sometimes enqueueing jobs could take a little bit longer. This is now done one a different thread making sure that enqueueing jobs goes as fast as possible.
  • MicroMeter integration: if you were using JobRunr with a framework like Spring, Micronaut or Quarkus and have MicroMeter on the classpath, it would automatically enable metrics for the enqueued / failed / succeeded jobs on each BackgroundJobServer. As it uses the same heave database aggregation as above, this is now opt-in (or done on the server that hosts the dashboard as it is needed anyway) only, instead of enabled by default on each BackgroundJobServer. You can still opt-in manually using properties.
  • for MongoDB: we did some performance improvements related to slow queries in MongoDB
• Stability improvement As most of you know, JobRunr stops processing after 5 severe exceptions (e.g. when your database goes down, ... ). This also happened when for some reason there was a ConcurrentJobModificationException. JobRunr is now smarter and after a successful run of the JobZooKeeper, the counter will now also go down. The main purpose for this counter is still to detect database outages (if JobRunr would not stop when a database outage happens, it would flood your logs immediately) and stop processing.

New features in JobRunr Pro

• Dashboard improvements:
  • Recurring Jobs: The recurring jobs view has improved ... a lot! You can now search for Recurring Jobs by name, label, nextRun, ... . This comes in handy when you have a lot of recurring jobs.
  • Jobs: The jobs views has also seen some love and you can now also search for jobs by id and by recurring job id. This allows you to have an instant overview of all the different job instances for a certain recurring job.
  • Other improvements: you will now also see the server tags in the Background Job Server tab
• Queues improvements: a queue name should be an enum and this is now possible! When creating a job for a certain queue, you can now just pass an enum! To setup your queues, you can now also use the following property: org.jobrunr.queues.from-enum=your.package.QueueName where you pass the fully qualified class name to your enum containing the different queues.

Some great new features to take in JobRunr Pro take your job scheduling to the next level:

• Custom Authentication Provider: You can now plugin your own Authentication Provider allowing to plug in custom authentication
• Real-time enqueueing: JobRunr Pro will by default do real-time enqueueing - e.g. if you schedule a Job each night at 8pm, it will now also be enqueued exactly at 8pm (unless you have more than 1000 jobs to enqueue at that time as otherwise it may have a huge performance impact).

The following features are present in JobRunr Pro Enterprise except for our early adopters and great existing customers 🙏:

• Secured dashboard: The JobRunr dashboard now supports OpenId Connect (only OpenId Connect. OAuth2 and SAML is in the works). The OpenId authentication plugin has been tested with Google, Okta, Keycloak and Spring Authorization Server. And it gets even better: if somebody manually intervenes (delete, requeue, ...) with a job using the dashboard, this is now audited!
• Embedded dashboard in Spring: JobRunr can now be embedded completely inside your existing Spring container (Micronaut & Quarkus are planned for 6.1). This means that you can also add custom authentication & security using Spring Security.
• Unlimited Recurring Jobs: Not only the Recurring Jobs Dashboard has improved a lot, you can now also create an (almost) unlimited amount of Recurring Jobs. JobRunr Pro Enterprise makes a difference between recurring jobs that run every minute or less (these are kept in memory) and recurring jobs that run less frequently than once per minute (which are requested from the database). This allows to have almost an unlimited amount of Recurring Jobs. We have personally tested with up to 15.000 Recurring Jobs that run on a certain timestamp.- Recurring Jobs skipped during downtime: You can now configure JobRunr to also run Recurring Jobs that were missed during downtime (e.g. because of deployments, ... ). If this happened, JobRunr will create a new scheduled job for each skipped run that happened during the downtime.
• Recurring Job instances running parallel: You can now configure JobRunr to also run job instances of a recurring job in parallel. By default, if a RecurringJob takes longer than the interval it is running, the run will be skipped as otherwise you may end up with creating more jobs than you can process. As of JobRunr 6 however, you can define how many instances of a Recurring Job can run in parallel.

Bugfixes:

• DST issue: JobRunr had an issue related to saving timestamps to the DB - which we discussed in our blog post. This has now been solved and JobRunr 6 wi...

v6.0.0-M2

JobRunr v6.0.0-M2

🥳 We're happy to announce the third Milestone release of JobRunr v6! 🥳

Improvements compared to JobRunr v6-M1:

• Bugfix related to Amazon DocumentDB.

v6.0.0-M1

JobRunr v6.0.0-M1

🥳 We're happy to announce the second Milestone release of JobRunr v6! 🥳

Improvements compared to JobRunr v6-M0:

• PR 653: Allow for multiple JobSchedulers with different table prefixes inside one application
• Update of all transitive dependencies

v6.0.0-M0

JobRunr v6.0.0-M0

🥳 We're happy to announce the first Milestone release of JobRunr v6! 🥳

New features in JobRunr

This includes a lot of new functionality and improvements:

• Job Builders: You can now create jobs using the JobBuilder and RecurringJobBuilder which allows you to configure all the aspects of a Job via this builder instead of the @Job annotation. This means you can now have one api to create jobs with different settings (including name and amount of retries).
  An example on how to use the JobBuilder:

jobScheduler.create(aJob()
    .withName("My Enqueued Job")
    .withAmountOfRetries(3)
    .withDetails(() -> service.doWork()));

Off course, you can also schedule jobs:

jobScheduler.create(aJob()
    .withName("My Scheduled Job")
    .scheduleAt(Instant.parse(scheduleAt))
    .withDetails(() -> service.doWork()));

And this also works for JobRequests:

jobRequestScheduler.create(aJob()
    .withName("Scan " + file.getName() + " for viruses")
    .scheduleIn(Duration.ofMinutes(10))
    .withJobRequest(new ScanFileForVirusJobRequest(file.getAbsolutePath())));

• Job Labels: Support for Job Labels! From now on, you can tag jobs with labels (think of a tenant / customer id / ... ). These labels will be visible in the dashboard. Oh, and in the pro version, you can search for labels in the dashboard!
  A label can be added both via the existing @Job annotation or the new JobBuilder:

@Job(name="My Job", labels={"fast-running-job", "tenant-%0"})
void myFastJob(String tenandId) {
 // your business logic
}

jobScheduler.create(aJob()
    .withName("My Enqueued Job")
    .withLabels("fast-running-job", "tenant-" + tenantId)
    .withDetails(() -> service.doWork()));

• Server name visible in dashboard: from now on, the server name is also visible in the dashboard. Under the tab BackgroundJobServers, you will see the host name of each server. This is also configurable and can be controlled via Spring Boot / Micronaut / Quarkus properties
• Spring Boot 3 AOT support: As of JobRunr 6, we generate new artifacts for spring, one for projects on Spring Boot 3 and one for projects still on Spring Boot 2:

<dependency>
    <groupId>org.jobrunr</groupId>
    <artifactId>jobrunr-spring-boot-2-starter</artifactId>
    <version>${jobrunr.version}</version>
</dependency>

<dependency>
    <groupId>org.jobrunr</groupId>
    <artifactId>jobrunr-spring-boot-3-starter</artifactId>
    <version>${jobrunr.version}</version>
</dependency>

The jobrunr-spring-boot-3-starter will automatically participate in the ahead-of-time processing if you're using a JobRequest.

• MDC Support during success and failure of a job: when a Job fails or succeeds, this was already automatically logged. But, you now also have access to all your MDC variables when the success or failure message is logged. Two extra MDC variables have been added: jobrunr.jobId and jobrunr.jobName.
• Performance improvements:
  • on job enqueue: whenever a Job is created, a notification is sent so the dashboard figures can be updated. As this is quite a heavy database aggregation, sometimes enqueueing jobs could take a little bit longer. This is now done one a different thread making sure that enqueueing jobs goes as fast as possible.
  • MicroMeter integration: if you were using JobRunr with a framework like Spring, Micronaut or Quarkus and have MicroMeter on the classpath, it would automatically enable metrics for the enqueued / failed / succeeded jobs on each BackgroundJobServer. As it uses the same heave database aggregation as above, this is now opt-in (or done on the server that hosts the dashboard as it is needed anyway) only, instead of enabled by default on each BackgroundJobServer. You can still opt-in manually using properties.
  • for MongoDB: we did some performance improvements related to slow queries in MongoDB
• Stability improvement As most of you know, JobRunr stops processing after 5 severe exceptions (e.g. when your database goes down, ... ). This also happened when for some reason there was a ConcurrentJobModificationException. JobRunr is now smarter and after a successful run of the JobZooKeeper, the counter will now also go down. The main purpose for this counter is still to detect database outages (if JobRunr would not stop when a database outage happens, it would flood your logs immediately) and stop processing.

New features in JobRunr Pro

Some great new features to take your job scheduling to the next level:

• Custom Authentication Provider: You can now plugin your own Authentication Provider allowing to plug in custom authentication
• Queues improvements: a queue name should be an enum and this is now possible! When creating a job for a certain queue, you can now just pass an enum! To setup your queues, you can now also use the following property: org.jobrunr.queues.from-enum=your.package.QueueName where you pass the fully qualified class name to your enum containing the different queues.
• Recurring Jobs skipped during downtime: You can now configure JobRunr to also run Recurring Jobs that were missed during downtime (e.g. because of deployments, ... ). If this happened, JobRunr will create a new scheduled job for each skipped run that happened during the downtime.
• Recurring Job instances running parallel: You can now configure JobRunr to also run job instances of a recurring job in parallel. By default, if a RecurringJob takes longer than the interval it is running, the run will be skipped as otherwise you may end up with creating more jobs than you can process. As of JobRunr 6 however, you can define how many instances of a Recurring Job can run in parallel.
• Real-time enqueueing: JobRunr Pro will by default do real-time enqueueing - e.g. if you schedule a Job each night at 8pm, it will now also be enqueued exactly at 8pm (unless you have more than 1000 jobs to enqueue at that time as otherwise it may have a huge performance impact).
• Dashboard improvements:
  • Recurring Jobs: The recurring jobs view has improved ... a lot! You can now search for Recurring Jobs by name, label, nextRun, ... . This comes in handy when you have a lot of recurring jobs.
  • Jobs: The jobs views has also seen some love and you can now also search for jobs by id and by recurring job id. This allows you to have an instant overview of all the different job instances for a certain recurring job.
  • Other improvements: you will now also see the server tags in the Background Job Server tab

The following features are present in JobRunr Pro Platinum except for our early adopters and great existing customers 🙏:

• Secured dashboard: The JobRunr dashboard now supports OpenId Connect (only OpenId Connect. OAuth2 and SAML is in the works). The OpenId authentication plugin has been tested with Google, Okta, Keycloak and Spring Authorization Server. And it gets even better: if somebody manually intervenes (delete, requeue, ...) with a job using the dashboard, this is now audited!
• Embedded dashboard in Spring: JobRunr can now be embedded completely inside your existing Spring container (Micronaut & Quarkus are planned for 6.1). This means that you can also add custom authentication & security using Spring Security.
• Unlimited Recurring Jobs: Not only the Recurring Jobs Dashboard has improved a lot, you can now also create an (almost) unlimited amount of Recurring Jobs. JobRunr Pro Platinum makes a difference between recurring jobs that run every minute or less (these are kept in memory) and recurring jobs that run less frequently than once per minute (which are requested from the database). This allows to have almost an unlimited amount of Recurring Jobs. We have personally tested with up to 15.000 Recurring Jobs that run on a certain timestamp.

Bugfixes:

• DST issue: JobRunr had an issue related to saving timestamps to the DB - which we discussed in our blog post. This has now been solved and JobRunr 6 will automatically update all your scheduled jobs on initial start. **This means that if you have a lot of scheduled jobs, JobRunr will need some time ...

v5.3.3

New features

None

Bugfixes

• /issues/643: Logs not available anymore if job history is too long.

v5.3.2

New features

None

Bugfixes

• /issues/635: Better handling of deadlocks in MySQL and MariaDB
• /issues/632: Fix bug in serialization when using JSONB
• /issues/631: Fix bug when JobRunr is used in a shared cloud environment (e.g. Amazon ECS) and the JVM halts completely due to shifting the CPU to other processes

v5.3.1

New features

None

Bugfixes

/issues/581 JobRunr does not fail on null values for MDC
/issues/586 DBMigration is done multiple times if it takes too much time on first run
/issues/593 Inheritance in Background Jobs is not always working

v5.3.0

New features

• #563: Support for Spring Context Indexer
• #577: Support for Kotlin 1.7.20
• #578: Initial support for Spring Boot 3.0.0

Bugfixes

None