Celebration time!
I’m pleased to announce the release of JobRunr v4.0.0 (which is now available via Maven Central) and JobRunr Pro v4.0.0 which is available for customers with a subscription. As this is a major release, there are also some small breaking changes.
Some great new features to both JobRunr and JobRunr Pro!
New features in JobRunr
This release adds a ton of new improvements to JobRunr:
- Job Analysis Performance mode: when a job is analyzed for the first time, JobRunr checks whether it can be cached. If so, all subsequent calls will be a lot faster. If job is not cacheable this is displayed in the dashboard.
- JobRequest and JobRequestHandler: this release introduces the
JobRequest
andJobRequesthandler
. This is a new way to create jobs using the command / commandhandler pattern (meaning you can use objects instead of lambda’s to create background jobs). Read all about it in the updated documentation section. - Static method support: JobRunr can now create jobs using lambda’s referencing static methods.
- Updated JobRunr Spring Boot Starter with:
- Support for
@Recurring
annotation for Recurring jobs - Support for disabled Recurring jobs using “-”
- Support for multiple datasources in Spring (a specific datasource for JobRunr)
- Support for Spring Actuator Health Endpoint
- Support for Spring Actuator Metrics Endpoint
- Support for
- New Micronaut Integration with:
- Support for
@Recurring
annotation for Recurring jobs - Support for disabled Recurring jobs using “-”
- Support for multiple datasources in Micronaut (a specific datasource for JobRunr)
- Support for Micronaut Health Endpoint
- Support for Micronaut Metrics Endpoint
- Support for
- New Quarkus Extension with:
- Support for
@Recurring
annotation for Recurring jobs - Support for disabled Recurring jobs using “-”
- Support for multiple datasources in Quarkus (a specific datasource for JobRunr)
- Support for Quarkus Health Endpoint
- Support for Quarkus Metrics Endpoint
- Support for
- CPU Allocation Irregularities detection: as JobRunr uses NTP (network time protocol) and timeouts to detect if a
BackgroundJobServer
is still alive, it is important that the JVM does not stop too long. JVM’s can stop due to full garbage collection taking too long or if they are running on shared cloud hardware where resources are stealed by other processes. JobRunr now detects this and shows a warning in the dashboard as it can impact the cluster.
New features in JobRunr Pro
JobRunr Pro also received a lot of new features!
- Pause Recurring Jobs: you can now pause recurring jobs with a click from the dashboard. Later on, you can easily resume these recurring jobs.
- Job Migrations: on start, JobRunr Pro checks if there are jobs that cannot be found anymore. If there are jobs that do not exist anymore in the current version of your application, you can choose to delete them or even update them (this comes in handy when you have a lot of scheduled jobs in the future that you can now easily migrate!). Read more about it in the documentation.
- Database fault-tolerance: JobRunr by default stops processing jobs if the connection to the database is lost (see also why this happens in the FAQ). JobRunr Pro now is now fault-tolerant in this regard and automatically starts processing again the moment your database is back online.
Breaking changes:
- the enum
DatabaseOptions
moved to StorageProviderUtils. You will need to adapt your import. - the
pollIntervalInSeconds
can not be smaller than 5 or else an exception will be thrown. This is to not generate too much load on your SQL or noSQL database (and I think 5 seconds is even too low to be honest) - StateChanges are now validated: this will impact people who are using
ElectStateFilters
and are changing states that are not valid (e.g. fromFAILED
toSUCCEEDED
, fromPROCESSING
toPROCESSING
). Make sure to (unit) test theseElectStateFilters
against the latestJob
class. JobRunr.configure()....initialize()
now returns aJobRunrConfigurationResult
which contains theJobScheduler
and theJobRequestScheduler
. This is done to add support for scheduling jobs via Java 8 lambda’s and via theJobRequest
interface.BackgroundJobServerConfiguration andWorkerCountPolicy(BackgroundJobServerWorkerPolicy backgroundJobServerWorkerPolicy)
has been renamed toBackgroundJobServerConfiguration andBackgroundJobServerWorkerPolicy(BackgroundJobServerWorkerPolicy backgroundJobServerWorkerPolicy)
- the
JobContext.getMetadata()
method now returns an unmodifiable Map. To add metadata, you should now use theJobContext.saveMetadata(String, Object)
method
Code Quality
As always, I strive for clean code when I’m working on JobRunr (or any other project). That’s why this release got some extra love and fixes related to SonarQube.
๐ Special thanks to …
Pei-Tang, Neil, Federico, Kevin and Anatolijs for various pull requests and help with issues!
All improvements & bugfixes
- GitHub issue 40: JobRunr Pro - Upcasting of lamba method
- GitHub issue 82: JobRunr Pro - If DB connection is lost, retry to connect to it when it is back up
- GitHub issue 97: Integration with Micronaut
- GitHub issue 177: Quarkus Extension
- GitHub issue 178: Better Spring Boot Integration
- GitHub issue 179: Micronaut Integration
- GitHub issue 181: Integration with popular third-party application monitoring systems.
- GitHub issue 182: NPE when scheduling recurring job
- GitHub issue 184: ApplyStateFilter not be invoked while deleting a job
- GitHub issue 185: Cannot use JobContext in Quarkus
- GitHub issue 189: Spring Boot app getting crash at startup
- GitHub issue 191: Error logging is wrong in case of long Garbage Collection cycle
- GitHub issue 192: Full Garbage Collection cycle of more than 20 sec causes JobRunr to stop
- GitHub issue 197: Ability to intercept ClassNotFound/MethodNotFound exceptions
- GitHub issue 206: Faster Job analysis
- GitHub issue 207: Cannot create jobs of static methods
- GitHub issue 210: Severe JobRunr Exception
- GitHub issue 211: Custom CRON is not working
- GitHub issue 218: Race condition between job serialization and JobRunr logging
- GitHub issue 219: Honor tablePrefix configuration property value for MongoDB collections