The release of JobRunr 7.0 features support for virtual threads, enabled by default, for applications running JDK 21. Virtual threads enhance concurrency and reduce the overhead associated with traditional threads. They are particularly beneficial for I/O-bound jobs, allowing JobRunr to handle a more significant number of concurrent jobs. JobRunr 7.0 also maintains backward compatibility with Java 8. JobRunr 7.1, a recent maintenance release, now also supports virtual threads on GraalVM native mode.
The implementation detects if the application runs on JDK 21 and automatically switches to virtual threads without requiring manual configuration from developers. This seamless integration improves throughput for applications with high I/O operations by doubling the number of workers available to pick up jobs. However, traditional platform threads might offer better performance for CPU-intensive tasks, and JobRunr provides configurations to adjust thread usage according to specific application needs. Despite the automatic detection, developers have the option to configure this behavior. For example, if the workload is CPU-intensive rather than I/O-bound, developers might find that traditional platform threads perform better. JobRunr allows these configurations to be adjusted according to the application's specific needs.
org.jobrunr.background-job-server.thread-type=PlatformThreads
#or org.jobrunr.background-job-server.thread-type=VirtualThreads
Developers can customize virtual thread settings via application properties or JobRunr’s API, giving them control over how threads are utilized, ensuring optimal performance tailored to their applications' requirements. Similar to other frameworks that have defaulted to JDK 21, this update marks a significant enhancement in JobRunr's capabilities, aligning it with the latest JDK 21. Furthermore, virtual threads are a substantial optimization for job processing efficiency.
JobRunr 7.0 has moved from traditional random UUIDs to time-based UUIDs, which are sequential and incorporate a time component. By using time-based UUIDs, JobRunr aims to enhance database performance. Databases typically index data using B-tree algorithms, and random UUIDs can lead to inefficiencies in storing and querying data. Time-based UUIDs provide a more sequential pattern that optimizes the B-tree's structure, leading to faster insertions and retrievals. The sequential nature of time-based UUIDs reduces the size of indexes on disk, which further helps with caching and reduces I/O operations.
Another notable enhancement is the InMemoryStorageProvider class. In the latest webinar, the JobRunr team alluded to this enhancement as part of the ongoing improvement and optimizations to JobRunr, even in aspects as fundamental as how jobs are stored and managed in memory. In version 7.0, this enhancement is geared toward development and testing use cases. For example, reducing the polling interval enhances the ability to test jobs. Faster polling means that the jobs scheduled for testing are processed quicker, reducing the overall time to test.
A good example could be automated testing during CI/CD pipelines. The InMemoryStorageProvider polling interval is reduced to 200 milliseconds. By default, the polling interval is set to 15 seconds. However, it can be changed as an argument to BackgroundJobServer or by using the property in the relevant framework. For example, setting the polling interval in Quarkus:
quarkus.jobrunr.background-job-server.poll-interval=15
The recurring job annotation, @Recurring, has moved from framework-specific packages, for example, Spring, Quarkus and Micronaut, to the core package to remove duplication. Developers can now exclude auto-configuration and use the recurring job instead. Furthermore, the annotation for paused and scheduleJobsSkippedDuringDowntime now uses enum instead of boolean. The paused state will allow further control during the redeployment of jobs. For example, if the paused state is set to false in the @Recurring annotation, it will not start on redeploy. This was different in the previous API where the job would be started automatically on a redeploy.
The RedisStorageProvider and ElasticSearchStorageProvider classes are also planned to be dropped. During the recent webinar, the authors pointed out this was due to a lack of usage and high maintenance costs. JobRunr 7 will be the last supported release for these providers. Moreover, the StorageProvider interface has been updated and is not backwards compatible, as are the Page and PageRequest classes, which are not used via the Paging class.
Another significant change for users is related to the backend MongoDB, where the DB driver is upgraded to version 5. This version is not backwards compatible, requiring users to update their driver versions manually if they use Spring Boot 3.2, which still relies on an older driver.
Ronald Dehuysser, the creator of JobRunr, spoke to InfoQ on this latest release and what’s on the horizon for JobRunr, stating:
JobRunr v7, featuring a revamped engine and significant performance enhancements across all databases, is our best release yet. It includes time-based UUIDs and the 'select for update skip locked' SQL feature, both of which minimize costs and environmental impact. Looking ahead, JobRunr v8 will introduce carbon-aware job scheduling, a feature designed to optimize the use of renewable energy and reduce CO2 emissions.
JobRunr 7 offers performance enhancements with its use of virtual threads. The new API promises more control. As with any major release, developers should be aware of the breaking changes. The JobRunr 7 team detailed the changes in their release blog and webinar.