Task scheduler in Java
JobRunr is an open-source Java library for task scheduling and distributed background job processing. It offers an effortless way to perform background tasks using only Java 8 lambdas.
Whether it is a fire-and-forget, scheduled or recurring job, JobRunr analyzes the lambda and stores the metadata needed to process the job in a database. This simple architecture, with a few other mechanisms, allows a job to be executed on any available server running your application (👋 k8s).
In the event of a failure, JobRunr automatically retries the job. Thanks to the built-in dashboard, it's easy to monitor the system to see why a job failed or to perform actions such as requeuing or deleting a job.
The software integrates easily into any Java application by adding JobRunr as a dependency. It also works seamlessly with frameworks like Spring Boot, Quarkus, and Micronaut.
JobRunr use cases in Java
The applications of JobRunr are almost limitless: anything that can be done in Java can be automated and scheduled with JobRunr. Would you like to send mass notifications, fire webhooks, process images, or videos? JobRunr can do it all for you, so you can focus on solving the business problems at hand.
JobRunr is used in various industries from retail to healthcare to marketing, no matter the size of your company. We have written a few articles about how JobRunr Pro is used in those industries.
Core task scheduler features for Developers:
Developer friendly: the API of JobRunr is simple, flexible and straightforward - with a simple, yet extensive set up.
Simple adoption: JobRunr fits into any software architecture and requires little changes to your codebase while requiring a low amount of dependencies.
Framework integration: JobRunr supports the most popular Java frameworks: Spring, Quarkus and Micronaut.
Various storage options: persistent storage is done via either RDBMS (e.g. Postgres, MariaDB/MySQL, Oracle, SQL Server, DB2, and SQLite) or NoSQL (ElasticSearch, MongoDB and Redis)
Cloud-native and cloud agnostic: deployable anywhere, either on your preferred cloud provider or on-premise
Distributed processing: scale is not an issue - JobRunr supports job distribution across a cluster.
Fault tolerance: JobRunr is also fault-tolerant - is an external web service down? No worries, the job is automatically retried 10-times with a smart back-off policy. The retry policy is of course configurable!
Real-time monitoring: JobRunr provides a dashboard that allows users to monitor jobs, trigger or delete recurring jobs, and requeue or delete jobs.
Virtual threads: JobRunr supports virtual threads to allow for increased throughput of I/O jobs.
Comprehensive documentation: the documentation covers everything from setup to advanced features, easing the learning curve.
Stay tuned for more of getting started with JobRunr and its implementation!😉
Authors: Ismaila Abdoulahi, Ronald Dehuysser, Donata Petkeviciute
Top comments (6)
I’d like to ask about the approach to the following scenario. How is it handled by JobRunr?
We have two kinds of tasks:
Right now we’re using a db-scheduler. It works really well, but to handle this case, we need to create three independent tables, one for each of the tasks.
I have a few questions for clarification:
recurring infinite task, is it a recurring task with a predefined schedule?Well, JobRunr needs in total 5 tables (as it manages all the ddl migrations for you). From what I know, db-scheduler only needs one table.
I think it's more related to your exact use case where you want to limit the amount of threads per pod which forces you to create more tables or in this case more db-scheduler instances. I might be wrong of-course as I don't know your architecture.
What you could do is create multiple pods, and limit the amount of workers (=threads) to 50 on each pod. Then you just fire jobs away (e.g. 1 million of SmallTaskB) and due to the limited amount of workers, you will only process 50 SmallTaskB per pod.
However if you create another job, it will be enqueued and stay in the queue until those 1 million SmallTaskB jobs are finished.
In pro, you have job priorities which can mitigate this but tbh, you're the second one asking for per pod rate limiting so we've put it on our backlog.
If you want, I can invite you to just google for JobRunr. There are now quite some blog posts explaining how to use it as also some YouTube video's (one of them from Josh Long 🤩 )
Anyway - if you're happy with db-scheduler by Kag, I can also highly recommend it and don't see the need for change. It also has great features like the select-for-update-skip-locked.
I think some extra features which are nice like the dashboard and the developer-friendliness when creating a job but overall I think the 2 libraries are both great.
Of-course I'm a bit biased as I'm the original creator of JobRunr so don't take my word for it 😊. Feel free to try it out and provide us with feedback.
We are currently using JobRunr where we have scheduled recurring job to anaylze multiple microservies logs after x hours.
This is helping us a lot to stabilise the application under test.
We are using REST endpoint to trigger the job.
Currently wanted to understand how to make a Junit test case to test JobRunr functionality. Do the test need to wait for X hours?
Thanks for the nice words!
You can just test your actual service / code and see that that code does it job.
You can also check whether the recurring job exists but it is up to you to decide whether you think it is necessary.
Hope this helps!