An extremely easy way to perform background processing in Java. Backed by persistent storage. Open and free for commercial use.

Overview

JobRunr logo

The ultimate library to perform background processing on the JVM.
Dead simple API. Extensible. Reliable.
Distributed and backed by persistent storage.
Open and free for commercial use.


  Drone Build  LGPLv3 Licence
Quality Scale  Reliability Rating  Security Rating
Coverage  Vulnerabilities  Bugs
Tweet about us!  Star us! Join the chat at Gitter

Overview

BackgroundJob.enqueue(() -> System.out.println("This is all you need for distributed jobs!"));

Incredibly easy way to perform fire-and-forget, delayed, scheduled and recurring jobs inside Java applications using only Java 8 lambda's. CPU and I/O intensive, long-running and short-running jobs are supported. Persistent storage is done via either RDBMS (e.g. Postgres, MariaDB/MySQL and Oracle) or NoSQL (ElasticSearch, MongoDB and Redis).

JobRunr provides a unified programming model to handle background tasks in a reliable way and runs them on shared hosting, dedicated hosting or in the cloud (hello Kubernetes) within a JVM instance.

Feedback

Thanks for building JobRunr, I like it a lot! Before that I used similar libraries in Ruby and Golang and JobRunr so far is the most pleasant one to use. I especially like the dashboard, it’s awesome! Alex Denisov

View more feedback on jobrunr.io.

Features

  • Simple: just use Java 8 lambda's to create a background job.
  • Distributed & cluster-friendly: guarantees execution by single scheduler instance using optimistic locking.
  • Persistent jobs: using either a RDMBS (four tables and a view) or a noSQL data store.
  • Embeddable: built to be embedded in existing applications.
  • Minimal dependencies: (ASM, slf4j and either jackson and jackson-datatype-jsr310, gson or a JSON-B compliant library).

Usage scenarios

Some scenarios where it may be a good fit:

  • within a REST api return response to client immediately and perform long-running job in the background
  • mass notifications/newsletters
  • calculations of wages and the creation of the resulting documents
  • batch import from xml, csv or json
  • creation of archives
  • firing off web hooks
  • image/video processing
  • purging temporary files
  • recurring automated reports
  • database maintenance
  • updating elasticsearch/solr after data changes
  • …and so on

You can start small and process jobs within your web app or scale horizontally and add as many background job servers as you want to handle a peak of jobs. JobRunr will distribute the load over all the servers for you. 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.

JobRunr is a Java alternative to HangFire, Resque, Sidekiq, delayed_job, Celery and is similar to Quartz and Spring Task Scheduler.

Screenshots

   
   
   

Usage

Fire-and-forget tasks

Dedicated worker pool threads execute queued background jobs as soon as possible, shortening your request's processing time.

BackgroundJob.enqueue(() -> System.out.println("Simple!"));

Delayed tasks

Scheduled background jobs are executed only after a given amount of time.

BackgroundJob.schedule(() -> System.out.println("Reliable!"), Instant.now().plusHours(5));

Recurring tasks

Recurring jobs have never been simpler; just call the following method to perform any kind of recurring task using the CRON expressions.

BackgroundJob.scheduleRecurringly("my-recurring-job", () -> service.doWork(), Cron.daily());

Process background tasks inside a web application…

You can process background tasks in any web application and we have thorough support for Spring - JobRunr is reliable to process your background jobs within a web application.

… or anywhere else

Like a Spring Console Application, wrapped in a docker container, that keeps running forever and polls for new background jobs.

See https://www.jobrunr.io for more info.

Installation

Using Maven?

JobRunr is available in Maven Central - all you need to do is add the following dependency:

<dependency>
   <groupId>org.jobrunr</groupId>
<artifactId>jobrunr</artifactId>
<version>1.2.2</version>
</dependency>

Using Gradle?

Just add the dependency to JobRunr:

implementation 'org.jobrunr:jobrunr:1.2.2'

Configuration

Do you like to work Spring based?

Add the jobrunr-spring-boot-starter to your dependencies and you're almost ready to go! Just set up your application.properties:

# the job-scheduler is enabled by default
# the background-job-server and dashboard are disabled by default
org.jobrunr.job-scheduler.enabled=true
org.jobrunr.background-job-server.enabled=true
org.jobrunr.dashboard.enabled=true

Or do you prefer a fluent API?

Define a javax.sql.DataSource and put the following code on startup:

@SpringBootApplication
public class JobRunrApplication {

    public static void main(String[] args) {
        SpringApplication.run(JobRunrApplication.class, args);
    }

    @Bean
    public JobScheduler initJobRunr(DataSource dataSource, JobActivator jobActivator) {
        return JobRunr.configure()
                .useStorageProvider(SqlStorageProviderFactory
                          .using(dataSource))
                .useJobActivator(jobActivator)
                .useDefaultBackgroundJobServer()
                .useDashboard()
                .initialize();
    }
}

Contributing

See CONTRIBUTING for details on submitting patches and the contribution workflow.

How can I contribute?

  • Take a look at issues with tag called Good first issue
  • Join the discussion on gitter.
  • Answer questions on issues.
  • Fix bugs reported on issues, and send us pull request.
Comments
  • [BUG] Jobrunr Skipping Recurring Jobs

    [BUG] Jobrunr Skipping Recurring Jobs

    After facing an issue of random skipping of daily recurring Jobs, we made a small POC to test the performance of Jobrunr compared to Spring Scheduler and Quartz and see if this issue occurs with them. Jobs for all 3 are configured to run every minute 0 * * * * * . I print the log for the count and timstamp of each job executed.

    Jobrunr Code:

    jobScheduler.scheduleRecurrently(
        "jobrunr-job",
        "0 * * * * *",
        () -> printLog());
    

    prinlog() Function:

    printLog() {
        log.info("JobRunr C: {}, T: {}", ++count, new Date());
    }
    

    In above defined logs, C is count and T is Timestamp. Similar logs for Spring Scheduler and Quartz.

    After about 1000-5000 minutes(I've reproduced the issue multiple times) a Jobrunr Job is skipped. See logs to see comparison of Jobrunr with Spring Scheduler and Quartz. We believe expected behaviour should be Job is never skipped. This issue is also reproduced with Jobrunr 5.

    Logs when Jobrunr job executing as expected:

    2022-04-29 03:34:59.988 DEBUG 16571 --- [pool-1-thread-2] o.j.s.s.BasicWorkDistributionStrategy    : Can onboard 16 new work (occupiedWorkerCount = 0; workerCount = 16).
    2022-04-29 03:34:59.989 DEBUG 16571 --- [pool-1-thread-2] org.jobrunr.server.JobZooKeeper          : checkForEnqueuedJobs [Job{id=fefffeb0-b1b9-4aad-afa6-34c8bf23ec3e, version='2', identity='1433322619', jobSignature='com.vadion.jobschedulingpoc.jobrunr.JobRunrJob.printLog()', jobName='com.vadion.jobschedulingpoc.jobrunr.JobRunrJob.printLog()', jobState='ENQUEUED', updatedAt='2022-04-29T03:34:59.988065Z'}]
    2022-04-29 03:34:59.989 DEBUG 16571 --- [pool-1-thread-2] org.jobrunr.server.BackgroundJobServer   : Submitted BackgroundJobPerformer for job fefffeb0-b1b9-4aad-afa6-34c8bf23ec3e to executor service
    2022-04-29 03:34:59.989 DEBUG 16571 --- [pool-2-thread-4] o.jobrunr.server.BackgroundJobPerformer  : Job(id=fefffeb0-b1b9-4aad-afa6-34c8bf23ec3e, jobName='com.vadion.jobschedulingpoc.jobrunr.JobRunrJob.printLog()') processing started
    2022-04-29 03:34:59.989  INFO 16571 --- [pool-2-thread-4] c.v.jobschedulingpoc.jobrunr.JobRunrJob  : JobRunr C: 1074, T: Fri Apr 29 03:34:59 UTC 2022
    2022-04-29 03:34:59.989 DEBUG 16571 --- [pool-2-thread-4] o.jobrunr.server.BackgroundJobPerformer  : Job(id=fefffeb0-b1b9-4aad-afa6-34c8bf23ec3e, jobName='com.vadion.jobschedulingpoc.jobrunr.JobRunrJob.printLog()') processing succeeded
    2022-04-29 03:34:59.989 DEBUG 16571 --- [pool-2-thread-4] org.jobrunr.server.JobZooKeeper          : Looking for enqueued jobs... 
    2022-04-29 03:34:59.989 DEBUG 16571 --- [pool-2-thread-4] o.j.s.s.BasicWorkDistributionStrategy    : Can onboard 16 new work (occupiedWorkerCount = 0; workerCount = 16).
    2022-04-29 03:34:59.989 DEBUG 16571 --- [pool-2-thread-4] org.jobrunr.server.JobZooKeeper          : checkForEnqueuedJobs []
    2022-04-29 03:35:00.000 DEBUG 16571 --- [SchedulerThread] org.quartz.core.QuartzSchedulerThread    : batch acquisition of 0 triggers
    2022-04-29 03:35:00.000 DEBUG 16571 --- [ryBean_Worker-4] org.quartz.core.JobRunShell              : Calling execute on job DEFAULT.quartz-job
    2022-04-29 03:35:00.000  INFO 16571 --- [ryBean_Worker-4] c.v.jobschedulingpoc.quartz.QuartzJob    : Quartz C: 1074, T: Fri Apr 29 03:35:00 UTC 2022
    2022-04-29 03:35:00.000  INFO 16571 --- [   scheduling-1] c.v.j.spring.SpringScheduler             : Spring C: 1074, T: Fri Apr 29 03:35:00 UTC 2022
    

    Logs when Jobrunr job skipped:

    2022-04-29 03:35:44.998 DEBUG 16571 --- [pool-1-thread-2] o.j.s.s.BasicWorkDistributionStrategy    : Can onboard 16 new work (occupiedWorkerCount = 0; workerCount = 16).
    2022-04-29 03:35:44.998 DEBUG 16571 --- [pool-1-thread-2] org.jobrunr.server.JobZooKeeper          : checkForEnqueuedJobs []
    2022-04-29 03:35:51.200 DEBUG 16571 --- [SchedulerThread] org.quartz.core.QuartzSchedulerThread    : batch acquisition of 1 triggers
    2022-04-29 03:35:59.998 DEBUG 16571 --- [pool-1-thread-2] org.jobrunr.server.JobZooKeeper          : Updating currently processed jobs... 
    2022-04-29 03:35:59.999 DEBUG 16571 --- [pool-1-thread-2] org.jobrunr.server.JobZooKeeper          : Looking for recurring jobs... 
    2022-04-29 03:35:59.999 DEBUG 16571 --- [pool-1-thread-2] org.jobrunr.server.JobZooKeeper          : Found 1 recurring jobs
    2022-04-29 03:35:59.999 DEBUG 16571 --- [pool-1-thread-2] org.jobrunr.server.JobZooKeeper          : mustSchedule RecurringJob{id=jobrunr-job, version='0', identity='619098969', jobSignature='com.vadion.jobschedulingpoc.jobrunr.JobRunrJob.printLog()', jobName='com.vadion.jobschedulingpoc.jobrunr.JobRunrJob.printLog()'}
    2022-04-29 03:36:00.000  INFO 16571 --- [   scheduling-1] c.v.j.spring.SpringScheduler             : Spring C: 1075, T: Fri Apr 29 03:36:00 UTC 2022
    2022-04-29 03:36:00.001 DEBUG 16571 --- [SchedulerThread] org.quartz.core.QuartzSchedulerThread    : batch acquisition of 0 triggers
    2022-04-29 03:36:00.001 DEBUG 16571 --- [ryBean_Worker-5] org.quartz.core.JobRunShell              : Calling execute on job DEFAULT.quartz-job
    2022-04-29 03:36:00.001  INFO 16571 --- [ryBean_Worker-5] c.v.jobschedulingpoc.quartz.QuartzJob    : Quartz C: 1075, T: Fri Apr 29 03:36:00 UTC 2022
    

    Logs after Jobrunr job skipped:

    2022-04-29 03:36:45.017 DEBUG 16571 --- [pool-1-thread-2] o.j.s.s.BasicWorkDistributionStrategy    : Can onboard 16 new work (occupiedWorkerCount = 0; workerCount = 16).
    2022-04-29 03:36:45.018 DEBUG 16571 --- [pool-1-thread-2] org.jobrunr.server.JobZooKeeper          : checkForEnqueuedJobs [Job{id=7e917712-6f54-4a44-a1e5-37fbe9ae989f, version='2', identity='2081810801', jobSignature='com.vadion.jobschedulingpoc.jobrunr.JobRunrJob.printLog()', jobName='com.vadion.jobschedulingpoc.jobrunr.JobRunrJob.printLog()', jobState='ENQUEUED', updatedAt='2022-04-29T03:36:45.016793Z'}]
    2022-04-29 03:36:45.018 DEBUG 16571 --- [pool-1-thread-2] org.jobrunr.server.BackgroundJobServer   : Submitted BackgroundJobPerformer for job 7e917712-6f54-4a44-a1e5-37fbe9ae989f to executor service
    2022-04-29 03:36:45.018 DEBUG 16571 --- [pool-2-thread-5] o.jobrunr.server.BackgroundJobPerformer  : Job(id=7e917712-6f54-4a44-a1e5-37fbe9ae989f, jobName='com.vadion.jobschedulingpoc.jobrunr.JobRunrJob.printLog()') processing started
    2022-04-29 03:36:45.018  INFO 16571 --- [pool-2-thread-5] c.v.jobschedulingpoc.jobrunr.JobRunrJob  : JobRunr C: 1075, T: Fri Apr 29 03:36:45 UTC 2022
    2022-04-29 03:36:45.018 DEBUG 16571 --- [pool-2-thread-5] o.jobrunr.server.BackgroundJobPerformer  : Job(id=7e917712-6f54-4a44-a1e5-37fbe9ae989f, jobName='com.vadion.jobschedulingpoc.jobrunr.JobRunrJob.printLog()') processing succeeded
    2022-04-29 03:36:45.018 DEBUG 16571 --- [pool-2-thread-5] org.jobrunr.server.JobZooKeeper          : Looking for enqueued jobs... 
    2022-04-29 03:36:45.018 DEBUG 16571 --- [pool-2-thread-5] o.j.s.s.BasicWorkDistributionStrategy    : Can onboard 16 new work (occupiedWorkerCount = 0; workerCount = 16).
    2022-04-29 03:36:45.018 DEBUG 16571 --- [pool-2-thread-5] org.jobrunr.server.JobZooKeeper          : checkForEnqueuedJobs []
    2022-04-29 03:36:52.294 DEBUG 16571 --- [SchedulerThread] org.quartz.core.QuartzSchedulerThread    : batch acquisition of 1 triggers
    2022-04-29 03:37:00.001 DEBUG 16571 --- [ryBean_Worker-6] org.quartz.core.JobRunShell              : Calling execute on job DEFAULT.quartz-job
    2022-04-29 03:37:00.001  INFO 16571 --- [   scheduling-1] c.v.j.spring.SpringScheduler             : Spring C: 1076, T: Fri Apr 29 03:37:00 UTC 2022
    2022-04-29 03:37:00.001 DEBUG 16571 --- [SchedulerThread] org.quartz.core.QuartzSchedulerThread    : batch acquisition of 0 triggers
    2022-04-29 03:37:00.001  INFO 16571 --- [ryBean_Worker-6] c.v.jobschedulingpoc.quartz.QuartzJob    : Quartz C: 1076, T: Fri Apr 29 03:37:00 UTC 2022
    

    Code for POC can be found here: https://github.com/BilalKamran/job-scheduling-poc

    bug help / PR wanted 
    opened by BilalKamran 40
  • Add kotlin-support module to allow enqueueing Kotlin lambda functions

    Add kotlin-support module to allow enqueueing Kotlin lambda functions

    Fixes #77

    This is a very preliminary pass but wanted to get feedback on it before adding the bells and whistles, more test cases, etc. Please let me know if you agree with the overall direction

    Sub tasks:

    • [x] Simple function type with no bound variables
    • [x] Capture bound variables
    • [x] Recurring job support
    • [ ] support for lambda parameters (passed to the invoke method)
    • [x] method references
    opened by felipecsl 34
  • [Feature] Add support for enqueueing Kotlin functional types

    [Feature] Add support for enqueueing Kotlin functional types

    Right now calling jobScheduler.enqueue (or scheduleRecurrently) with a Kotlin lambda fails since the semantics of how they are implemented internally are different from Java lambdas.

    I have a fork of jobrunr with work in progress to support this use case but before I keep going down the path of making it a mergeable change, I wanted to run it by you to see if there's any interest on adding support for that. If so, I can go ahead and continue polishing it and might be able to submit a pull request in the next few days.

    Let me know what your thoughts are!

    enhancement help / PR wanted Awaiting feedback 
    opened by felipecsl 30
  • Severe JobRunr Exception

    Severe JobRunr Exception

    SevereJobRunrException occurred in BackgroundJobServer 89d7c0b4-19ab-4da1-93bb-5e34e7629426: Could not resolve ConcurrentJobModificationException

    Runtime information

    • Timestamp: 2022-01-21T05:41:34.990173023Z
    • Location: BackgroundJobServer 89d7c0b4-19ab-4da1-93bb-5e34e7629426
    • JobRunr Version: 4.0.1
    • StorageProvider: org.jobrunr.storage.sql.mariadb.MariaDbStorageProvider
    • Java Version: 15.0.1
    • Is running from nested jar: false

    Background Job Servers

    • BackgroundJobServer id: 89d7c0b4-19ab-4da1-93bb-5e34e7629426 (workerPoolSize: 4, pollIntervalInSeconds: 5, firstHeartbeat: 2022-01-21T05:40:38.121464Z, lastHeartbeat: 2022-01-21T05:41:33.343126Z)

    Diagnostics from exception

    Concurrent modified jobs:

    Job id: eab73d9e-3c68-4249-852a-c82d14a098e8 Local version: 5; Storage version: 6 Local state: DELETED (at 2022-01-21T05:41:04.576913404Z) ← PROCESSING (at 2022-01-21T05:41:04.537562334Z on BackgroundJobServer 89d7c0b4-19ab-4da1-93bb-5e34e7629426) ← ENQUEUED (at 2022-01-21T05:36:05.000067844Z) Storage state: DELETED (at 2022-01-21T05:41:01.534887099Z) ← PROCESSING (at 2022-01-21T05:40:59.403639452Z on BackgroundJobServer 89d7c0b4-19ab-4da1-93bb-5e34e7629426) ← ENQUEUED (at 2022-01-21T05:36:05.000067844Z)

    Exception

    org.jobrunr.SevereJobRunrException: Could not resolve ConcurrentJobModificationException
    	at org.jobrunr.server.JobZooKeeper.processJobList(JobZooKeeper.java:214)
    	at org.jobrunr.server.JobZooKeeper.updateJobsThatAreBeingProcessed(JobZooKeeper.java:89)
    	at org.jobrunr.server.JobZooKeeper.run(JobZooKeeper.java:74)
    	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    	at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:305)
    	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)
    	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
    	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
    	at java.base/java.lang.Thread.run(Thread.java:832)
    
    

    SevereJobRunrException occurred in BackgroundJobServer 8ce1ecda-52c8-4034-9d41-8cc6a0a5a1b0: Could not resolve ConcurrentJobModificationException

    Runtime information

    • Timestamp: 2022-01-22T03:48:19.624264531Z
    • Location: BackgroundJobServer 8ce1ecda-52c8-4034-9d41-8cc6a0a5a1b0
    • JobRunr Version: 4.0.1
    • StorageProvider: org.jobrunr.storage.sql.mariadb.MariaDbStorageProvider
    • Java Version: 15.0.1
    • Is running from nested jar: false

    Background Job Servers

    • BackgroundJobServer id: 8ce1ecda-52c8-4034-9d41-8cc6a0a5a1b0 (workerPoolSize: 4, pollIntervalInSeconds: 5, firstHeartbeat: 2022-01-22T03:46:05.448662Z, lastHeartbeat: 2022-01-22T03:48:19.568798Z)

    Diagnostics from exception

    Concurrent modified jobs:

    Job id: 8f72af34-9efb-424c-9a51-9b8bdd12c25a Local version: 12; Storage version: 13 Local state: SCHEDULED (at 2022-01-22T03:48:19.589220618Z) ← FAILED (at 2022-01-22T03:48:19.583438212Z) ← PROCESSING (at 2022-01-22T03:47:26.967061153Z on BackgroundJobServer 8ce1ecda-52c8-4034-9d41-8cc6a0a5a1b0) Storage state: SUCCEEDED (at 2022-01-22T03:48:19.568197190Z) ← PROCESSING (at 2022-01-22T03:47:26.967061153Z on BackgroundJobServer 8ce1ecda-52c8-4034-9d41-8cc6a0a5a1b0) ← ENQUEUED (at 2022-01-22T03:47:25.748309585Z)

    Exception

    org.jobrunr.SevereJobRunrException: Could not resolve ConcurrentJobModificationException
    	at org.jobrunr.server.JobZooKeeper.processJobList(JobZooKeeper.java:214)
    	at org.jobrunr.server.JobZooKeeper.processJobList(JobZooKeeper.java:198)
    	at org.jobrunr.server.JobZooKeeper.checkForOrphanedJobs(JobZooKeeper.java:124)
    	at org.jobrunr.server.JobZooKeeper.runMasterTasksIfCurrentServerIsMaster(JobZooKeeper.java:96)
    	at org.jobrunr.server.JobZooKeeper.run(JobZooKeeper.java:75)
    	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    	at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:305)
    	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)
    	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
    	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
    	at java.base/java.lang.Thread.run(Thread.java:832)
    
    
    wontfix 
    opened by datnguyen293 20
  • [BUG] Database migration don't run when executing spring-boot jar

    [BUG] Database migration don't run when executing spring-boot jar

    Describe the bug When executing my project using "mvn spring-boot:run" everything runs fine, database migrations are executed on my postgress db. During the test phase"mvn clean package" migrations are executed on my in memory H2 database. But when I run my application "java -jar target/app.jar" migrations aren't executed and Jobrunr fails with exception;

    2021-01-11 18:01:02.355 ERROR 32675 --- [pool-1-thread-1] org.jobrunr.server.ServerZooKeeper       : An unrecoverable error occurred. Shutting server down...
    
    org.jobrunr.storage.StorageException: org.h2.jdbc.JdbcSQLSyntaxErrorException: Table "JOBRUNR_BACKGROUNDJOBSERVERS" not found; SQL statement:
    

    This is the case with both H2 and Postgres, the in-memory storage provider works fine. There are no log entries regarding a failed or skipped migration.

    Environment I'm using version: 1.2.3 I'm running on JRE / JDK: openjdk 11.0.9.1 2020-11-04 (with maven and java scope) I'm using the following StorageProvider: SQL

    To Reproduce The error occurs both while defining the config in "application.properties" and using a config Bean (the first is also there in my example but commented). I've isolated the problem in a "plain" spring-boot project, without any additional code: https://github.com/wijnandtop/jobrunr_issue

    mvn clean package
    java -jar target/demo-0.0.1-SNAPSHOT.jar
    

    Expected behavior JobRunr check if migrations are needed if sol the migrations are executed and JobRunr starts. I don't want to run them manually since I create dynamic environments for CI.

    Additional context Maybe I'm missing something and I made a mistake, I did spend a couple of hours on this, so if it is the case it may be worth documenting it.

    bug 
    opened by wijnandtop 19
  • [BUG] Not all the recurring jobs are getting scheduled

    [BUG] Not all the recurring jobs are getting scheduled

    Are you running the latest version of JobRunr? Yes

    Describe the bug This is to reopen bug in https://github.com/jobrunr/jobrunr/issues/426. Details provided in bug#426

    Environment I'm using JobRunr version: 5.0.1 I'm running on JRE / JDK: java 11 I'm using the following StorageProvider : MongoDB Atlas

    How to Reproduce I have create github repo SchedulerService. @rdehuyss, I have provided access to you. Please let me know if anyone else needs to get access to this. It has a create schedule API. Details of this API are available in readMe file. This issue occurs with storage provider MongoDB Atlas. The recurring job occurence used is Daily.

    bug 
    opened by ms-precisely 16
  • Unrecoverable error on time change due to daylight saving timezone change

    Unrecoverable error on time change due to daylight saving timezone change

    Are you running the latest version of JobRunr? Yes

    Describe the bug It seems that jobrunr does not handle daylight time zone change properly. We have a couple of jobrunr containers on a server that has daylight timezone change enabled. On 30.10.2022 at 02:00 all our containers died with following exception:

    2022-10-30 02:00:04,126 ERROR - An unrecoverable error occurred. Shutting server down...
    org.jobrunr.JobRunrException: JobRunr encountered a problematic exception. Please create a bug report (if possible, provide the code to reproduce this and the stacktrace)
    	at org.jobrunr.JobRunrException.shouldNotHappenException(JobRunrException.java:33) ~[jobrunr-5.3.0.jar:5.3.0]
    	at org.jobrunr.storage.sql.common.BackgroundJobServerTable.lambda$getLongestRunningBackgroundJobServerId$3(BackgroundJobServerTable.java:98) ~[jobrunr-5.3.0.jar:5.3.0]
    	at java.util.Optional.orElseThrow(Optional.java:403) ~[?:?]
    	at org.jobrunr.storage.sql.common.BackgroundJobServerTable.getLongestRunningBackgroundJobServerId(BackgroundJobServerTable.java:98) ~[jobrunr-5.3.0.jar:5.3.0]
    	at org.jobrunr.storage.sql.common.DefaultSqlStorageProvider.getLongestRunningBackgroundJobServerId(DefaultSqlStorageProvider.java:116) ~[jobrunr-5.3.0.jar:5.3.0]
    	at org.jobrunr.storage.ThreadSafeStorageProvider.getLongestRunningBackgroundJobServerId(ThreadSafeStorageProvider.java:74) ~[jobrunr-5.3.0.jar:5.3.0]
    	at org.jobrunr.server.ServerZooKeeper.determineIfCurrentBackgroundJobServerIsMaster(ServerZooKeeper.java:115) ~[jobrunr-5.3.0.jar:5.3.0]
    	at org.jobrunr.server.ServerZooKeeper.signalBackgroundJobServerAliveAndDoZooKeeping(ServerZooKeeper.java:79) ~[jobrunr-5.3.0.jar:5.3.0]
    	at org.jobrunr.server.ServerZooKeeper.run(ServerZooKeeper.java:49) [jobrunr-5.3.0.jar:5.3.0]
    	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
    	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
    	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
    	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
    	at java.lang.Thread.run(Thread.java:833) [?:?]
    Caused by: java.lang.IllegalStateException: No servers available?!
    	... 15 more
    

    I presume that following happened: All servers had heartbeat around 03:00 (or a little bit before). Then, at 03:00 time has been shifted to 02:00, thus jobrunr could not find any living server, subsequently it considered itself unable to handle further request and shut down:

    2022-10-30 02:00:04,128  INFO - BackgroundJobServer and BackgroundJobPerformers - stopping (waiting for all jobs to complete - max 10 seconds)
    2022-10-30 02:00:04,159  INFO - BackgroundJobServer and BackgroundJobPerformers stopped
    

    I also presume that similar thing may occur on 26.03.2023 when time will be shifted from 02:00 to 03:00 due to another timezone change.

    opened by raffig 15
  • [BUG] Jobs are scheduled with the same parameters even though different parameters are provided

    [BUG] Jobs are scheduled with the same parameters even though different parameters are provided

    Are you running the latest version of JobRunr? Yes

    Describe the bug We have a Job class with a run method that takes a uuid as it's parameter. We then enqueue the jobs using the following call:

    BackgroundJob.enqueue(() -> new OurJob().run(id));
    

    This works perfectly fine for the first run in the process but if we call this multiple times with different id's it creates the jobs with the first id over and over. We've validated that our id's are indeed different each time so there has to be a problem in JobRunr or the way we are using it.

    As we are not running in Spring, we are providing a pretty simple activator but from what I understand this doesn't really matter as our job class doesn't contain any fields and the dashboard also shows the wrong id so they are already getting scheduled with the wrong parameters.

    new JobActivator() {
        public <T> T activateJob(Class<T> aClass) {
            try {
                return aClass.newInstance();
            } catch (InstantiationException | IllegalAccessException e) {
                e.printStackTrace();
            }
            return null;
        }
    }
    

    Environment I'm using JobRunr version: 4.0.6 I'm running on JRE / JDK (e.g. OpenJDK 1.8.0_292): OpenJDK 1.8.0_302 I'm using the following StorageProvider (e.g. Oracle / MongoDB / ...): MariaDB

    How to Reproduce

    public class OurJob {
      public void run(UUID id) {
        System.out.println(id);
      }
    }
    
    BackgroundJob.enqueue(() -> new OurJob().run(UUID.randomUUID()));
    BackgroundJob.enqueue(() -> new OurJob().run(UUID.randomUUID()));
    

    Expected behavior The job should get scheduled with 2 different id's.

    bug Awaiting feedback 
    opened by JanHolger 14
  • WANTED: who is using JobRunr?

    WANTED: who is using JobRunr?

    Who is Using JobRunr

    First of all, thanks sincerely for using and supporting JobRunr. I will try my best to make JobRunr better, and keep the community and eco-system growing.

    The purpose of this issue

    • I’d like to listen to the community to make JobRunr better.
    • I'm willing to learn more JobRunr use-case scenarios from the field for better planning.

    What I expect from you

    Pls. submit a comment in this issue and include the following information:

    • your company, school or organization.
    • your city and country.
    • your contact info: blog, email, twitter (at least one).
    • for what business scenario do you use JobRunr

    You can refer to the following sample answer for the format:

    * Organization: Rosoco
    * Location: Leuven, Belgium
    * Contact: [email protected]
    * Purpose: used as cornerstone in a distributed service architecture for generating a large amount of documents.
    

    Thanks again for your participation !

    pinned 
    opened by rdehuyss 14
  • [BUG] Dockerized Jobrunr Inside JHipster Project Is Not Starting

    [BUG] Dockerized Jobrunr Inside JHipster Project Is Not Starting

    Are you running the latest version of JobRunr? Yes

    Describe the bug I don't know how I can manage it but it runs once. But after that build it stopped to working. I using postgresql 13.2 and jhipster server in same docker-compose instance.

    Environment I'm using JobRunr version: 5.1.0 and 5.0.1 I'm running on JRE / JDK (e.g. OpenJDK 1.8.0_292): OpenJDK 13 I'm using the following StorageProvider (e.g. Oracle / MongoDB / ...): PostgreSql

    Dockerfile:

    FROM jhipster/jhipster:latest
    USER root
    ADD . /code/
    RUN rm -Rf /code/target /code/build /code/node_modules && \
        cd /code/ && \
        chmod +x mvnw && \
        ./mvnw clean package -Pprod -DskipTests && \
        mv /code/target/*.jar /app.jar
    
    FROM openjdk:13-jdk-alpine3.9
    ENV SPRING_OUTPUT_ANSI_ENABLED=ALWAYS \
        JHIPSTER_SLEEP=0 \
        JAVA_OPTS=""
    EXPOSE 80 443
    CMD echo "The application will start in ${JHIPSTER_SLEEP}s..." && \
        sleep ${JHIPSTER_SLEEP} && \
        java ${JAVA_OPTS} -Djava.security.egd=file:/dev/./urandom -jar /app.jar
    COPY --from=0 /app.jar .
    

    How to Reproduce Project building in Github CI. I using ubuntu-latest as system.

    Expected behavior Runs in docker container.

    Additional context

    The application will start in 2s...
    
    Picked up _JAVA_OPTIONS: -Xmx512m -Xms256m
    
    
            ██╗ ██╗   ██╗ ████████╗ ███████╗   ██████╗ ████████╗ ████████╗ ███████╗
    
            ██║ ██║   ██║ ╚══██╔══╝ ██╔═══██╗ ██╔════╝ ╚══██╔══╝ ██╔═════╝ ██╔═══██╗
    
            ██║ ████████║    ██║    ███████╔╝ ╚█████╗     ██║    ██████╗   ███████╔╝
    
      ██╗   ██║ ██╔═══██║    ██║    ██╔════╝   ╚═══██╗    ██║    ██╔═══╝   ██╔══██║
    
      ╚██████╔╝ ██║   ██║ ████████╗ ██║       ██████╔╝    ██║    ████████╗ ██║  ╚██╗
    
       ╚═════╝  ╚═╝   ╚═╝ ╚═══════╝ ╚═╝       ╚═════╝     ╚═╝    ╚═══════╝ ╚═╝   ╚═╝
    
    
    :: JHipster 🤓  :: Running Spring Boot 2.4.4 ::
    
    :: https://www.jhipster.tech ::
    
    
    2022-05-09 20:12:38.477 DEBUG 1 --- [kground-preinit] org.jboss.logging                        : Logging Provider: org.jboss.logging.Log4j2LoggerProvider
    
    2022-05-09 20:12:38.517  INFO 1 --- [           main] com.bironbir.BirOnBirApp                 : Starting BirOnBirApp using Java 13-ea on 4179aae3a5cb with PID 1 (/app.jar started by root in /)
    
    2022-05-09 20:12:38.519 DEBUG 1 --- [           main] com.bironbir.BirOnBirApp                 : Running with Spring Boot v2.4.4, Spring v5.3.5
    
    2022-05-09 20:12:38.520  INFO 1 --- [           main] com.bironbir.BirOnBirApp                 : The following profiles are active: prod,api-docs
    
    2022-05-09 20:12:39.669  WARN 1 --- [kground-preinit] o.s.h.c.j.Jackson2ObjectMapperBuilder    : For Jackson Kotlin classes support please add "com.fasterxml.jackson.module:jackson-module-kotlin" to the classpath
    
    2022-05-09 20:12:44.723 ERROR 1 --- [           main] o.j.u.r.ClassPathResourceProvider        : Could not close FileSystemProvider
    
    
    java.nio.file.ClosedFileSystemException: null
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.ensureOpen(ZipFileSystem.java:1155)
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.checkAccess(ZipFileSystem.java:355)
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipPath.checkAccess(ZipPath.java:865)
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipPath.toRealPath(ZipPath.java:180)
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipPath.toRealPath(ZipPath.java:60)
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.lambda$removeFileSystem$0(ZipFileSystemProvider.java:320)
    
    	at java.base/java.security.AccessController.doPrivileged(AccessController.java:553)
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.removeFileSystem(ZipFileSystemProvider.java:322)
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.close(ZipFileSystem.java:323)
    
    	at org.jobrunr.utils.resources.JarFileSystemProvider.close(JarFileSystemProvider.java:53)
    
    	at org.jobrunr.utils.resources.ClassPathResourceProvider.close(ClassPathResourceProvider.java:109)
    
    	at org.jobrunr.storage.sql.common.migrations.DefaultSqlMigrationProvider.getMigrations(DefaultSqlMigrationProvider.java:18)
    
    	at org.jobrunr.storage.sql.common.DatabaseMigrationsProvider.getCommonMigrations(DatabaseMigrationsProvider.java:49)
    
    	at org.jobrunr.storage.sql.common.DatabaseMigrationsProvider.getMigrations(DatabaseMigrationsProvider.java:31)
    
    	at org.jobrunr.storage.sql.common.DatabaseCreator.getMigrations(DatabaseCreator.java:103)
    
    	at org.jobrunr.storage.sql.common.DatabaseCreator.runMigrations(DatabaseCreator.java:78)
    
    	at org.jobrunr.storage.sql.common.DefaultSqlStorageProvider.setUpStorageProvider(DefaultSqlStorageProvider.java:64)
    
    	at org.jobrunr.storage.sql.common.DefaultSqlStorageProvider.<init>(DefaultSqlStorageProvider.java:52)
    
    	at org.jobrunr.storage.sql.common.DefaultSqlStorageProvider.<init>(DefaultSqlStorageProvider.java:40)
    
    	at org.jobrunr.storage.sql.postgres.PostgresStorageProvider.<init>(PostgresStorageProvider.java:24)
    
    	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    
    	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    
    	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    
    	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)
    
    	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481)
    
    	at org.jobrunr.storage.sql.common.SqlStorageProviderFactory.getStorageProvider(SqlStorageProviderFactory.java:69)
    
    	at org.jobrunr.storage.sql.common.SqlStorageProviderFactory.getStorageProviderByJdbcUrl(SqlStorageProviderFactory.java:44)
    
    	at org.jobrunr.storage.sql.common.SqlStorageProviderFactory.getStorageProviderUsingDataSource(SqlStorageProviderFactory.java:36)
    
    	at org.jobrunr.storage.sql.common.SqlStorageProviderFactory.using(SqlStorageProviderFactory.java:30)
    
    	at org.jobrunr.spring.autoconfigure.storage.JobRunrSqlStorageAutoConfiguration.sqlStorageProvider(JobRunrSqlStorageAutoConfiguration.java:36)
    
    	at org.jobrunr.spring.autoconfigure.storage.JobRunrSqlStorageAutoConfiguration$$EnhancerBySpringCGLIB$$97c5de24.CGLIB$sqlStorageProvider$0(<generated>)
    
    	at org.jobrunr.spring.autoconfigure.storage.JobRunrSqlStorageAutoConfiguration$$EnhancerBySpringCGLIB$$97c5de24$$FastClassBySpringCGLIB$$7d7423f.invoke(<generated>)
    
    	at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244)
    
    	at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:331)
    
    	at org.jobrunr.spring.autoconfigure.storage.JobRunrSqlStorageAutoConfiguration$$EnhancerBySpringCGLIB$$97c5de24.sqlStorageProvider(<generated>)
    
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    
    	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    
    	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
    
    	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:653)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:638)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1334)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1177)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:564)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:524)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335)
    
    	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208)
    
    	at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:276)
    
    	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1380)
    
    	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1300)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:887)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:791)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:541)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1334)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1177)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:564)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:524)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335)
    
    	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208)
    
    	at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:276)
    
    	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1380)
    
    	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1300)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:887)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:791)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:541)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1334)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1177)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:564)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:524)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335)
    
    	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:213)
    
    	at org.springframework.context.support.PostProcessorRegistrationDelegate.registerBeanPostProcessors(PostProcessorRegistrationDelegate.java:270)
    
    	at org.springframework.context.support.AbstractApplicationContext.registerBeanPostProcessors(AbstractApplicationContext.java:762)
    
    	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:567)
    
    	at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:144)
    
    	at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:769)
    
    	at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:761)
    
    	at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:426)
    
    	at org.springframework.boot.SpringApplication.run(SpringApplication.java:326)
    
    	at com.bironbir.BirOnBirApp.main(BirOnBirApp.java:86)
    
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    
    	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    
    	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
    
    	at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:49)
    
    	at org.springframework.boot.loader.Launcher.launch(Launcher.java:107)
    
    	at org.springframework.boot.loader.Launcher.launch(Launcher.java:58)
    
    	at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:88)
    
    
    2022-05-09 20:12:44.735  WARN 1 --- [           main] ConfigServletWebServerApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'recurringJobPostProcessor' defined in class path resource [org/jobrunr/spring/autoconfigure/JobRunrAutoConfiguration.class]: Unsatisfied dependency expressed through method 'recurringJobPostProcessor' parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'jobScheduler' defined in class path resource [org/jobrunr/spring/autoconfigure/JobRunrAutoConfiguration.class]: Unsatisfied dependency expressed through method 'jobScheduler' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'storageProvider' defined in class path resource [org/jobrunr/spring/autoconfigure/storage/JobRunrSqlStorageAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.jobrunr.storage.StorageProvider]: Factory method 'sqlStorageProvider' threw exception; nested exception is org.jobrunr.JobRunrException: JobRunr encountered a problematic exception. Please create a bug report (if possible, provide the code to reproduce this and the stacktrace)
    
    2022-05-09 20:12:44.806 ERROR 1 --- [           main] o.s.boot.SpringApplication               : Application run failed
    
    
    org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'recurringJobPostProcessor' defined in class path resource [org/jobrunr/spring/autoconfigure/JobRunrAutoConfiguration.class]: Unsatisfied dependency expressed through method 'recurringJobPostProcessor' parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'jobScheduler' defined in class path resource [org/jobrunr/spring/autoconfigure/JobRunrAutoConfiguration.class]: Unsatisfied dependency expressed through method 'jobScheduler' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'storageProvider' defined in class path resource [org/jobrunr/spring/autoconfigure/storage/JobRunrSqlStorageAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.jobrunr.storage.StorageProvider]: Factory method 'sqlStorageProvider' threw exception; nested exception is org.jobrunr.JobRunrException: JobRunr encountered a problematic exception. Please create a bug report (if possible, provide the code to reproduce this and the stacktrace)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:800)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:541)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1334)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1177)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:564)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:524)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335)
    
    	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:213)
    
    	at org.springframework.context.support.PostProcessorRegistrationDelegate.registerBeanPostProcessors(PostProcessorRegistrationDelegate.java:270)
    
    	at org.springframework.context.support.AbstractApplicationContext.registerBeanPostProcessors(AbstractApplicationContext.java:762)
    
    	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:567)
    
    	at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:144)
    
    	at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:769)
    
    	at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:761)
    
    	at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:426)
    
    	at org.springframework.boot.SpringApplication.run(SpringApplication.java:326)
    
    	at com.bironbir.BirOnBirApp.main(BirOnBirApp.java:86)
    
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    
    	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    
    	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
    
    	at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:49)
    
    	at org.springframework.boot.loader.Launcher.launch(Launcher.java:107)
    
    	at org.springframework.boot.loader.Launcher.launch(Launcher.java:58)
    
    	at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:88)
    
    Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'jobScheduler' defined in class path resource [org/jobrunr/spring/autoconfigure/JobRunrAutoConfiguration.class]: Unsatisfied dependency expressed through method 'jobScheduler' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'storageProvider' defined in class path resource [org/jobrunr/spring/autoconfigure/storage/JobRunrSqlStorageAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.jobrunr.storage.StorageProvider]: Factory method 'sqlStorageProvider' threw exception; nested exception is org.jobrunr.JobRunrException: JobRunr encountered a problematic exception. Please create a bug report (if possible, provide the code to reproduce this and the stacktrace)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:800)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:541)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1334)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1177)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:564)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:524)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335)
    
    	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208)
    
    	at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:276)
    
    	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1380)
    
    	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1300)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:887)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:791)
    
    	... 26 common frames omitted
    
    Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'storageProvider' defined in class path resource [org/jobrunr/spring/autoconfigure/storage/JobRunrSqlStorageAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.jobrunr.storage.StorageProvider]: Factory method 'sqlStorageProvider' threw exception; nested exception is org.jobrunr.JobRunrException: JobRunr encountered a problematic exception. Please create a bug report (if possible, provide the code to reproduce this and the stacktrace)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:658)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:638)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1334)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1177)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:564)
    
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:524)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335)
    
    	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333)
    
    	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208)
    
    	at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:276)
    
    	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1380)
    
    	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1300)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:887)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:791)
    
    	... 40 common frames omitted
    
    Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.jobrunr.storage.StorageProvider]: Factory method 'sqlStorageProvider' threw exception; nested exception is org.jobrunr.JobRunrException: JobRunr encountered a problematic exception. Please create a bug report (if possible, provide the code to reproduce this and the stacktrace)
    
    	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185)
    
    	at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:653)
    
    	... 54 common frames omitted
    
    Caused by: org.jobrunr.JobRunrException: JobRunr encountered a problematic exception. Please create a bug report (if possible, provide the code to reproduce this and the stacktrace)
    
    	at org.jobrunr.JobRunrException.shouldNotHappenException(JobRunrException.java:43)
    
    	at org.jobrunr.storage.sql.common.SqlStorageProviderFactory.getStorageProvider(SqlStorageProviderFactory.java:71)
    
    	at org.jobrunr.storage.sql.common.SqlStorageProviderFactory.getStorageProviderByJdbcUrl(SqlStorageProviderFactory.java:44)
    
    	at org.jobrunr.storage.sql.common.SqlStorageProviderFactory.getStorageProviderUsingDataSource(SqlStorageProviderFactory.java:36)
    
    	at org.jobrunr.storage.sql.common.SqlStorageProviderFactory.using(SqlStorageProviderFactory.java:30)
    
    	at org.jobrunr.spring.autoconfigure.storage.JobRunrSqlStorageAutoConfiguration.sqlStorageProvider(JobRunrSqlStorageAutoConfiguration.java:36)
    
    	at org.jobrunr.spring.autoconfigure.storage.JobRunrSqlStorageAutoConfiguration$$EnhancerBySpringCGLIB$$97c5de24.CGLIB$sqlStorageProvider$0(<generated>)
    
    	at org.jobrunr.spring.autoconfigure.storage.JobRunrSqlStorageAutoConfiguration$$EnhancerBySpringCGLIB$$97c5de24$$FastClassBySpringCGLIB$$7d7423f.invoke(<generated>)
    
    	at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244)
    
    	at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:331)
    
    	at org.jobrunr.spring.autoconfigure.storage.JobRunrSqlStorageAutoConfiguration$$EnhancerBySpringCGLIB$$97c5de24.sqlStorageProvider(<generated>)
    
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    
    	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    
    	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
    
    	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154)
    
    	... 55 common frames omitted
    
    Caused by: java.lang.reflect.InvocationTargetException: null
    
    	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    
    	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    
    	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    
    	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)
    
    	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481)
    
    	at org.jobrunr.storage.sql.common.SqlStorageProviderFactory.getStorageProvider(SqlStorageProviderFactory.java:69)
    
    	... 69 common frames omitted
    
    Caused by: java.lang.IllegalStateException: Could not close FileSystemProvider
    
    	at org.jobrunr.utils.resources.ClassPathResourceProvider.close(ClassPathResourceProvider.java:113)
    
    	at org.jobrunr.storage.sql.common.migrations.DefaultSqlMigrationProvider.getMigrations(DefaultSqlMigrationProvider.java:18)
    
    	at org.jobrunr.storage.sql.common.DatabaseMigrationsProvider.getCommonMigrations(DatabaseMigrationsProvider.java:49)
    
    	at org.jobrunr.storage.sql.common.DatabaseMigrationsProvider.getMigrations(DatabaseMigrationsProvider.java:31)
    
    	at org.jobrunr.storage.sql.common.DatabaseCreator.getMigrations(DatabaseCreator.java:103)
    
    	at org.jobrunr.storage.sql.common.DatabaseCreator.runMigrations(DatabaseCreator.java:78)
    
    	at org.jobrunr.storage.sql.common.DefaultSqlStorageProvider.setUpStorageProvider(DefaultSqlStorageProvider.java:64)
    
    	at org.jobrunr.storage.sql.common.DefaultSqlStorageProvider.<init>(DefaultSqlStorageProvider.java:52)
    
    	at org.jobrunr.storage.sql.common.DefaultSqlStorageProvider.<init>(DefaultSqlStorageProvider.java:40)
    
    	at org.jobrunr.storage.sql.postgres.PostgresStorageProvider.<init>(PostgresStorageProvider.java:24)
    
    	... 75 common frames omitted
    
    Caused by: java.nio.file.ClosedFileSystemException: null
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.ensureOpen(ZipFileSystem.java:1155)
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.checkAccess(ZipFileSystem.java:355)
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipPath.checkAccess(ZipPath.java:865)
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipPath.toRealPath(ZipPath.java:180)
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipPath.toRealPath(ZipPath.java:60)
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.lambda$removeFileSystem$0(ZipFileSystemProvider.java:320)
    
    	at java.base/java.security.AccessController.doPrivileged(AccessController.java:553)
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.removeFileSystem(ZipFileSystemProvider.java:322)
    
    	at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.close(ZipFileSystem.java:323)
    
    	at org.jobrunr.utils.resources.JarFileSystemProvider.close(JarFileSystemProvider.java:53)
    
    	at org.jobrunr.utils.resources.ClassPathResourceProvider.close(ClassPathResourceProvider.java:109)
    
    	... 84 common frames omitted
    
    
    opened by centrual 13
  • [BUG] Scheduled jobs are not getting enqueued

    [BUG] Scheduled jobs are not getting enqueued

    Are you running the latest version of JobRunr? Yes

    Describe the bug Scheduled jobs are saved in relational database with status as SCHEDULED, but jobs are never ENQUEUED

    Environment I'm using JobRunr version: <4.0.3> I'm running on JRE / JDK <17> I'm using the following StorageProvider (e.g. Oracle / MongoDB / ...):

    How to Reproduce Provide a simple Github project or code fragment which shows how to reproduce the issue (ideally a Github repo).

    JobId jobId = BackgroundJob.schedule(Instant.now().plusSeconds(60), () -> System.out.println("Job completed"));
    

    Expected behavior after 60 seconds jobs should be processed.

    Additional context Jobs are always in SCHEDULED state.

    opened by ShubhajitM 13
  • Severe JobRunr Exception

    Severe JobRunr Exception

    SevereJobRunrException occurred in BackgroundJobServer 0878e3d7-870a-419b-9907-48ace44b19e6: Could not resolve ConcurrentJobModificationException

    Runtime information

    • Timestamp: 2022-12-31T05:16:05.504613461Z
    • Location: BackgroundJobServer 0878e3d7-870a-419b-9907-48ace44b19e6
    • JobRunr Version: 5.3.0
    • StorageProvider: org.jobrunr.storage.nosql.mongo.MongoDBStorageProvider
    • Java Version: 17.0.2
    • Is running from nested jar: true

    Background Job Servers

    • BackgroundJobServer id: 753e5449-7366-4d10-afd1-bf9990eb6f13 (workerPoolSize: 2, pollIntervalInSeconds: 15, firstHeartbeat: 2022-12-28T07:01:54.941Z, lastHeartbeat: 2022-12-31T05:15:53.695Z)

    Diagnostics from exception

    Concurrent modified jobs:

    Job id: 9d960d6b-ec06-45e4-abb0-b891669eb3c3 Local version: 16; Storage version: 17 Local state: PROCESSING (updated at 2022-12-31T05:16:05.222687209Z on BackgroundJobServer 0878e3d7-870a-419b-9907-48ace44b19e6 and started at 2022-12-31T05:13:45.285279698Z) ← ENQUEUED (at 2022-12-31T05:13:38.987602295Z) ← SCHEDULED (at 2022-12-31T05:10:08.740986209Z) ← FAILED (at 2022-12-31T05:10:08.740858303Z) ← PROCESSING (updated at 2022-12-31T05:08:55.781565968Z on BackgroundJobServer 0878e3d7-870a-419b-9907-48ace44b19e6 and started at 2022-12-31T05:07:53.859445961Z) ← ENQUEUED (at 2022-12-31T05:07:53.583656088Z) Storage state: SCHEDULED (at 2022-12-31T05:15:39.127407776Z) ← FAILED (at 2022-12-31T05:15:39.127194393Z) ← PROCESSING (updated at 2022-12-31T05:14:32.695860265Z on BackgroundJobServer 0878e3d7-870a-419b-9907-48ace44b19e6 and started at 2022-12-31T05:13:45.285279698Z) ← ENQUEUED (at 2022-12-31T05:13:38.987602295Z) ← SCHEDULED (at 2022-12-31T05:10:08.740986209Z) ← FAILED (at 2022-12-31T05:10:08.740858303Z)

    Exception

    org.jobrunr.SevereJobRunrException: Could not resolve ConcurrentJobModificationException
    	at org.jobrunr.server.JobZooKeeper.processJobList(JobZooKeeper.java:223)
    	at org.jobrunr.server.JobZooKeeper.updateJobsThatAreBeingProcessed(JobZooKeeper.java:91)
    	at org.jobrunr.server.JobZooKeeper.run(JobZooKeeper.java:75)
    	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
    	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
    	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
    	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
    	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    	at java.base/java.lang.Thread.run(Thread.java:833)
    opened by tifacom 4
  • [BUG] Jobs fail with

    [BUG] Jobs fail with "Orphaned job" error

    JobRunr Version

    5.3.2

    JDK Version

    openjdk version "17.0.5" 2022-10-18 LTS

    Your SQL / NoSQL database

    Postgresql 12.6

    What happened?

    We have long running jobs that download and upload big files to different places and take a considerable amount of time to finish. We've seen the following error a few times every day:

    java.lang.IllegalThreadStateException: Job was too long in PROCESSING state without being updated.
    	at org.jobrunr.server.JobZooKeeper.lambda$checkForOrphanedJobs$2(JobZooKeeper.java:126)
    	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
    	at org.jobrunr.server.JobZooKeeper.processJobList(JobZooKeeper.java:215)
    	at org.jobrunr.server.JobZooKeeper.processJobList(JobZooKeeper.java:207)
    	at org.jobrunr.server.JobZooKeeper.checkForOrphanedJobs(JobZooKeeper.java:126)
    	at org.jobrunr.server.JobZooKeeper.runMasterTasksIfCurrentServerIsMaster(JobZooKeeper.java:98)
    	at org.jobrunr.server.JobZooKeeper.run(JobZooKeeper.java:76)
    	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
    	at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:305)
    	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)
    	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
    	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
    	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    	at java.base/java.lang.Thread.run(Thread.java:833)
    

    Taking a look at the code it seems that this happens when a job hasn't been updated in 60 seconds (default 15 seconds polling multiplied by 4). It always happens with the jobs that process the bigger files because the download takes time and depending on network conditions it can take some minutes to finish.

    I'm wondering if this way of checking the orphaned jobs can be improved in some way or maybe the time to consider a job orphaned can be configured instead of being calculated as it is now.

    How to reproduce?

    It's hard to reproduce because it depends on network conditions. I'm able to reproduce it locally while debugging trying to download very big files that take a lot of time and also setting break points in some parts of the code to "stop" the execution.

    Relevant log output

    No response

    opened by ilopmar 3
  • Sql: Fixing statement cache when using tablePrefix

    Sql: Fixing statement cache when using tablePrefix

    The current statementCache does not consider the tablePrefix.

    The cache is a static concurrent hashmap, meaning that it will be shared among the different JobScheduler instances.When you configure multiple schedulers with different table prefixes, only one statement is created and cached because the cache key is built using the original query, which does not yet have the table prefix.

    As a result, only one tablePrefix is used at the end, while the others are left unused.

    Given that the map is static, my suggestion is to simply add the tablePrefix to the map's key.

    cla-signed 
    opened by raulgpdev 1
  • [Feature] - Change job schedule at runtime

    [Feature] - Change job schedule at runtime

    Is your feature request related to a problem? Please describe. In past versions of jobrunr (free version), ex. 4.x.x, it was possible to change a job schedule by modifying it's corresponding row in jobrunr_recurring_jobs table and by changing the scheduleExpression field. In 5.x.x version it is no more possible.

    Describe the solution you'd like We'd like to have this feature back and change the job schedule at runtime by changing entries in jobrunr_recurring_jobs table or, if it is not possible, in the dashboard.

    Describe alternatives you've considered An alternative we have considered is to launch manually the trigger for one single job from the dashboard, but it is not as effective as changing the row value and change the scheduleExpression field.

    enhancement Pro 
    opened by StefanoPaganoni 1
  • [Feature] Allow poll interval to be less than 5 seconds for InMemoryStorageProvider

    [Feature] Allow poll interval to be less than 5 seconds for InMemoryStorageProvider

    When writing integration tests it would be really useful if it would be possible to configure the poll interval to be less than 5 seconds so that the tests don't need to wait so long, especially when using the InMemoryStorageProvider. However, the standard BackgroundJobServerConfiguration won't allow this because andPollIntervalInSeconds throws an exception if pollIntervalInSeconds is less than 5. Preferably, the method should take a java.time.Duration instead of an integer so that we can configure it with e.g. 200 ms for testing purposes.

    enhancement 
    opened by johanhaleby 4
  • [Feature] Provide Liquibase and Flyway scripts

    [Feature] Provide Liquibase and Flyway scripts

    Is your feature request related to a problem? Please describe. There are few organizations which provides only option to create DML is using Flyway or Liquibase migrations for SQL Stores

    Describe the solution you'd like Flyway and Liquibase script per database so that It can be copied and executed in the project start up

    enhancement Pro 
    opened by rajadilipkolli 7
Releases(v5.3.2)
  • v5.3.2(Dec 11, 2022)

  • v5.3.1(Oct 30, 2022)

  • v5.3.0(Oct 3, 2022)

  • v5.2.0(Sep 23, 2022)

  • v5.1.8(Aug 26, 2022)

  • v5.1.7(Aug 14, 2022)

  • v5.1.6(Jul 21, 2022)

  • v5.1.5(Jul 13, 2022)

  • v5.1.4(Jun 17, 2022)

    New features

    • #472 JobRunr now can generate the necessary SQL migrations so they can be embedded in Flyway
    • #478 JobRunr page request size configuration for high volume job processing
    • #483 Allow to plugin in a custom BackgroundJobPerformer

    Bugfixes

    • #429 Fix Severe JobRunr Exception - ConcurrentJobModificationException when server hangs too long and other node takes over
    • #473 BackgroundJobServer can now be restarted if it was stopped because of database connection problems
    • #479 JobRunr does not detect provided JavaTimeModule provided by Jackson in some cases
    • #485 JobRunr 5.0 regression when using Quarkus
    • #489 Fix SQL migration for Oracle
    Source code(tar.gz)
    Source code(zip)
    core-5.1.4-javadoc.jar(2.01 MB)
    core-5.1.4-sources.jar(2.12 MB)
    core-5.1.4.jar(2.43 MB)
  • v5.1.3(Jun 2, 2022)

  • v5.1.2(May 20, 2022)

    New features

    • https://github.com/jobrunr/jobrunr/pull/454 @Recurring annotation now also supports an interval
    • Allow to set the JobContext using MockJobContext

    Bugfixes

    • https://github.com/jobrunr/jobrunr/issues/451 @Creator Jackson annotation now works in Kotlin
    • https://github.com/jobrunr/jobrunr/issues/456 Fix threading issue in CachingJobDetailsGenerator
    • Fix connection leak in JedisRedisStorageProvider and LettuceRedisStorageProvicer
    • Fix layout issue (enqueued state)
    Source code(tar.gz)
    Source code(zip)
    core-5.1.2-javadoc.jar(1.97 MB)
    core-5.1.2-sources.jar(2.12 MB)
    core-5.1.2.jar(2.43 MB)
  • v5.1.1(May 10, 2022)

  • v5.1.0(May 6, 2022)

    Improvements

    • #417 JobRunr now supports Kotlin 1.6.20

    Bugfixes

    • #432 JobRunrConfiguration.useJsonMapper doesn't update internal JobMapper
    • #431 The background server stops if JobDetails are not deserializable. JobRunr by default already checks whether all jobs exist (e.g. classes moved because of refactoring, ... ). If they do not exist, this is shown in the dashboard. However sometimes Job parameters change and they are not deserializable anymore. In this case, JobRunr would stop processing jobs due to too many deserialization exceptions. This is now solved and the job just fails. In the Pro version, you can now add a unit test using the JobMigrationGuard to validate whether all your jobs in production keep working with your local changes.
    • #427 java.nio.file.ClosedFileSystemException caused by race condition

    Miscellaneous

    On top of that JobRunr now also shares some anonymous data usage (the amount of succeeded jobs) for marketing purposes (a counter on the website how many jobs in total were processed by JobRunr 😂). Off-course you can opt-out for this using a simple setting.

    Source code(tar.gz)
    Source code(zip)
    core-5.1.0-javadoc.jar(1.97 MB)
    core-5.1.0-sources.jar(2.12 MB)
    core-5.1.0.jar(2.43 MB)
  • v5.0.1(Apr 18, 2022)

    Improvements

    • #411 Ability to keep dashboard logs after job success

    Bugfixes

    • #401 RetryFilter always falls into number of retries from Job annotation
    • #407 Newest version of JobRunr has dependency on Spring version with critical vulnerability
    • #416 Jobrunr failed to start With Jobrunr (jobrunr-spring-boot-starter 5.0.0) version when storage is Mongo Db after dockerized the application
    Source code(tar.gz)
    Source code(zip)
    core-5.0.1-javadoc.jar(1.96 MB)
    core-5.0.1-sources.jar(2.12 MB)
    core-5.0.1-test-fixtures.jar(114.72 KB)
    core-5.0.1.jar(2.42 MB)
  • v5.0.0(Mar 30, 2022)

    JobRunr 5.0.0 & JobRunr Pro 5.0.0 released!

    Celebration time!

    I'm pleased to announce the release of JobRunr v5.0.0 (which is now available via Maven Central) and JobRunr Pro v5.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 again adds quite some new improvements to JobRunr:

    • Scheduled jobs with repeating interval: since JobRunr 5.0.0, you can now schedule recurring jobs using an interval. This means you can now also schedule recurring jobs as follows: BackgroundJob.scheduleRecurringly("my-recurring-job", Duration.parse("PT5D"), () -> service.doWork()); Thank you @Daniela!
    • Spring Native support: Thanks to @JoshLong, JobRunr now out-of-the-box supports Spring Native. Use the dependency jobrunr-spring-boot-native and your app will launch in milliseconds.
    • MDC support: this release introduces support for the Mapped Diagnostics Context of SLF4J. If you have a correlation id available and you log something in your job, this correlation id will still be available. You can even use any value of the MDC context in the display name.
    • Cron extended with last day of month: Need to run some jobs on the last day of the month? This is now possible thanks to @asahaf as the JobRunr Cron expression parser now supports last-day-of-week and last-day-of-month syntax.
    • Default Number of Retries: You can now easily change the default number of retries via the JobRunr Spring Boot Starter, the Micronaut integration and the Quarkus Extension configuration.
    • Easier integration with multiple databases: Are you running the JobRunr Spring Boot Starter, the Micronaut integration or the Quarkus Extension and do you have multiple databases available in your application (e.g. an SQL database and a Mongo DB or ElasticSearch instance)? As of JobRunr 5.0.0, you can specify which database to use in this case thanks to the extended configuration. Just specify the database type and JobRunr will select that database.
    • MicroMeter integration: This release also adds support for MicroMeter in the JobRunr Fluent Api configuration.
    • Performance improvement: Before JobRunr 5.0.0, all the recurring jobs were constantly reloaded from the StorageProvider when JobRunr checked for new work. This is now cached and only reloaded when the number of jobs changes (e.g. a delete happens).
    • Dashboard ✋ Google: I noticed that there were some JobRunr dashboards publicly available and indexed by Google. As of now, the JobRunr dashboard has a noIndex and noFollow meta tag so that your jobs stay private.

    New features in JobRunr Pro

    JobRunr Pro also received a lot of new features!

    • Transaction plugin: are you running the JobRunr Spring Boot Starter, the Micronaut integration? Then as of v5.0.0, JobRunr out-of-the-box participates in the transactions created by these frameworks.
    • Instant processing: JobRunr Pro adds some magic and now comes with instant processing of jobs. Just enqueue a job and processing will instantly begin - no need to wait for the pollInterval.
    • Easy JobFilters: JobRunr has the concept of JobFilters to easily extend the functionality of JobRunr. In JobRunr Pro, this becomes even easier as any Spring / Micronaut / Quarkus bean that implements the JobClientFilter or JobServerFilter will automatically be registered in JobRunr.
    • Improved serverTags: JobRunr Pro uses ServerTags to specify on which server a Job can run. From now on, you can even limit to run a job on the same server that scheduled it using the annotation @Job(runOnServerWithTag = "%CURRENT_SERVER")
    • enqueueOrReplace and scheduleOrReplace: are you creating jobs with your own UUID? By default, JobRunr ignores any new job that is enqueued or scheduled if it was already created before as it allows to process jobs in a cluster only once. But do you need to replace that job for some reason? Using the new enqueueOrReplace and scheduleOrReplace methods it is now possible to update existing jobs at any point in the lifecycle of that job.
    • Job Results: do you want to return the result from your job to a client? JobRunr Pro now captures the result of a job, serializes it to JSON and saves it to the database. Using the JobScheduler, you can then query for the result of a job. It comes with a smart query algorithm that takes into account average processing time of that type of job and it makes sure that you don't overload the database if you for example have clients querying for the result in a while loop.
    • Dashboard improvements: the JobRunr Pro dashboard has improved a lot! You can now requeue or delete all failed jobs at once. A real time-saver.

    Breaking changes:

    • all existing recurring jobs are not compatible anymore due to the support for recurring jobs using an interval. Please make sure to have no recurring jobs nor scheduled jobs in your application before upgrading.
    • the job metadata is now cleared as soon as the job succeeded. There are 2 reasons for this: storage savings in your storage provider and the fact that it was used to return results from jobs without any back-off policy and thus negatively impacting the performance of JobRunr. But, JobRunr Pro now supports returning results from jobs!
    • if you are using ElasticSearch, you will need to update your ElasticSearch dependencies as a bug was introduced by Elastic in ElasticSearch 7.16
    • all dependencies have been updated to the latest version - make sure to upgrade your dependencies too.

    👏 Special thanks to ...

    Daniela Tumbraegel, ShawnNest for the PR's and Josh Long fun pairing session to add support for Spring Boot Native - the Spring guys are really amazing! I also want to thank Pei-Tang and Jan Holger for sponsoring me and making sure I have enough caffein!

    All improvements & bugfixes

    Source code(tar.gz)
    Source code(zip)
    core-5.0.0-javadoc.jar(1.96 MB)
    core-5.0.0-sources.jar(2.12 MB)
    core-5.0.0-test-fixtures.jar(114.25 KB)
    core-5.0.0.jar(2.42 MB)
  • v5.0.0-RC1(Mar 17, 2022)

    JobRunr 5.0.0-RC1 & JobRunr Pro 5.0.0-RC1

    Release candidate!

    Note: JobRunr 5.0.0 and JobRunr Pro 5.0.0 are currently release candidates. I expect to release JobRunr 5.0.0 by the end of March 2022.

    Celebration time!

    I'm pleased to announce the release of JobRunr v5.0.0 (which is now available via Maven Central) and JobRunr Pro v5.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 again adds quite some new improvements to JobRunr:

    • Scheduled jobs with repeating interval: since JobRunr 5.0.0, you can now schedule recurring jobs using an interval. This means you can now also schedule recurring jobs as follows: BackgroundJob.scheduleRecurringly("my-recurring-job", Duration.parse("PT5D"), () -> service.doWork()); Thank you @Daniela!
    • Spring Native support: Thanks to @JoshLong, JobRunr now out-of-the-box supports Spring Native. Use the dependency jobrunr-spring-boot-native and your app will launch in milliseconds.
    • MDC support: this release introduces support for the Mapped Diagnostics Context of SLF4J. If you have a correlation id available and you log something in your job, this correlation id will still be available. You can even use any value of the MDC context in the display name.
    • Cron extended with last day of month: Need to run some jobs on the last day of the month? This is now possible thanks to @asahaf as the JobRunr Cron expression parser now supports last-day-of-week and last-day-of-month syntax.
    • Default Number of Retries: You can now easily change the default number of retries via the JobRunr Spring Boot Starter, the Micronaut integration and the Quarkus Extension configuration.
    • Easier integration with multiple databases: Are you running the JobRunr Spring Boot Starter, the Micronaut integration or the Quarkus Extension and do you have multiple databases available in your application (e.g. an SQL database and a Mongo DB or ElasticSearch instance)? As of JobRunr 5.0.0, you can specify which database to use in this case thanks to the extended configuration. Just specify the database type and JobRunr will select that database.
    • MicroMeter integration: This release also adds support for MicroMeter in the JobRunr Fluent Api configuration.
    • Performance improvement: Before JobRunr 5.0.0, all the recurring jobs were constantly reloaded from the StorageProvider when JobRunr checked for new work. This is now cached and only reloaded when the number of jobs changes (e.g. a delete happens).
    • Dashboard ✋ Google: I noticed that there were some JobRunr dashboards publicly available and indexed by Google. As of now, the JobRunr dashboard has a noIndex and noFollow meta tag so that your jobs stay private.

    New features in JobRunr Pro

    JobRunr Pro also received a lot of new features!

    • Transaction plugin: are you running the JobRunr Spring Boot Starter, the Micronaut integration? Then as of v5.0.0, JobRunr out-of-the-box participates in the transactions created by these frameworks.
    • Instant processing: JobRunr Pro adds some magic and now comes with instant processing of jobs. Just enqueue a job and processing will instantly begin - no need to wait for the pollInterval.
    • Easy JobFilters: JobRunr has the concept of JobFilters to easily extend the functionality of JobRunr. In JobRunr Pro, this becomes even easier as any Spring / Micronaut / Quarkus bean that implements the JobClientFilter or JobServerFilter will automatically be registered in JobRunr.
    • Improved serverTags: JobRunr Pro uses ServerTags to specify on which server a Job can run. From now on, you can even limit to run a job on the same server that scheduled it using the annotation @Job(runOnServerWithTag = "%CURRENT_SERVER")
    • enqueueOrReplace and scheduleOrReplace: are you creating jobs with your own UUID? By default, JobRunr ignores any new job that is enqueued or scheduled if it was already created before as it allows to process jobs in a cluster only once. But do you need to replace that job for some reason? Using the new enqueueOrReplace and scheduleOrReplace methods it is now possible to update existing jobs at any point in the lifecycle of that job.
    • Job Results: do you want to return the result from your job to a client? JobRunr Pro now captures the result of a job, serializes it to JSON and saves it to the database. Using the JobScheduler, you can then query for the result of a job. It comes with a smart query algorithm that takes into account average processing time of that type of job and it makes sure that you don't overload the database if you for example have clients querying for the result in a while loop.
    • Dashboard improvements: the JobRunr Pro dashboard has improved a lot! You can now requeue or delete all failed jobs at once. A real time-saver.

    Breaking changes:

    • all existing recurring jobs are not compatible anymore due to the support for recurring jobs using an interval. Please make sure to have no recurring jobs nor scheduled jobs in your application before upgrading.
    • the job metadata is now cleared as soon as the job succeeded. There are 2 reasons for this: storage savings in your storage provider and the fact that it was used to return results from jobs without any back-off policy and thus negatively impacting the performance of JobRunr. But, JobRunr Pro now supports returning results from jobs!
    • if you are using ElasticSearch, you will need to update your ElasticSearch dependencies as a bug was introduced by Elastic in ElasticSearch 7.16
    • all dependencies have been updated to the latest version - make sure to upgrade your dependencies too.

    👏 Special thanks to ...

    Daniela Tumbraegel, ShawnNest for the PR's and Josh Long fun pairing session to add support for Spring Boot Native - the Spring guys are really amazing! I also want to thank Pei-Tang and Jan Holger for sponsoring me and making sure I have enough caffein!

    All improvements & bugfixes

    Source code(tar.gz)
    Source code(zip)
    core-5.0.0-RC1-javadoc.jar(1.96 MB)
    core-5.0.0-RC1-sources.jar(2.12 MB)
    core-5.0.0-RC1-test-fixtures.jar(114.25 KB)
    core-5.0.0-RC1.jar(2.42 MB)
  • v4.0.10(Mar 8, 2022)

  • v4.0.9(Feb 17, 2022)

  • v4.0.8(Feb 4, 2022)

  • v4.0.7(Jan 30, 2022)

  • v4.0.6(Jan 11, 2022)

  • v4.0.4(Dec 7, 2021)

  • v4.0.3(Nov 25, 2021)

  • v4.0.2(Nov 10, 2021)

  • v4.0.1(Oct 26, 2021)

  • v4.0.0(Sep 14, 2021)

    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!

    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 JobRequestScheduler a new way to create jobs using objects instead of lambda's. 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
    • 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
    • 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
    • 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.

    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. from FAILED to SUCCEEDED, from PROCESSING to PROCESSING). Make sure to (unit) test these ElectStateFilters against the latest Job class.
    • JobRunr.configure()....initialize() now returns a JobRunrConfigurationResult which contains the JobScheduler and the JobRequestScheduler. This is done to add support for scheduling jobs via Java 8 lambda's and via the JobRequest interface.
    • BackgroundJobServerConfiguration andWorkerCountPolicy(BackgroundJobServerWorkerPolicy backgroundJobServerWorkerPolicy) has been renamed to BackgroundJobServerConfiguration andBackgroundJobServerWorkerPolicy(BackgroundJobServerWorkerPolicy backgroundJobServerWorkerPolicy)
    • the JobContext.getMetadata() method now returns an unmodifiable Map. To add metadata, you should now use the JobContext.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

    Source code(tar.gz)
    Source code(zip)
    core-v4.0.0-javadoc.jar(1.89 MB)
    core-v4.0.0-sources.jar(2.45 MB)
    core-v4.0.0-test-fixtures.jar(102.83 KB)
    core-v4.0.0.jar(2.74 MB)
  • v4.0.0-RC3(Sep 10, 2021)

  • v4.0.0-RC1(Aug 30, 2021)

    This is release candidate 1 for v4.0.0, biggest release since v1.0.0.

    It contains a lot of improvements... stay tuned!

    needed to recreate the release due to publishing problems to Maven Central.

    Draft of improvements and breaking changes

    New features

    • 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.
    • Updated 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
    • New Micronaut feature 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
    • 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
    • CPU Allocation Irregularities detection: as JobRunr uses NTP 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.
    • JobRequest and JobRequestHandler: this release introduces the JobRequestScheduler a new way to create jobs using objects instead of lambda's.
    • Static method support: JobRunr can now create jobs using lambda's referencing static method

    Breaking changes:

    • the pollIntervalInSeconds can not be smaller than 5 or else an exception will be thrown
    • StateChanges are now validated. This will impact people who are using ElectStateFilters and are changing states that are not valid (e.g. from Failed to Succeeded, from Processing to Processing).
    • JobRunr.configure()....initialize() now returns a JobRunrConfigurationResult which contains the JobScheduler and the JobRequestScheduler
    • BackgroundJobServerConfiguration andWorkerCountPolicy(BackgroundJobServerWorkerPolicy backgroundJobServerWorkerPolicy) has been renamed to BackgroundJobServerConfiguration andBackgroundJobServerWorkerPolicy(BackgroundJobServerWorkerPolicy backgroundJobServerWorkerPolicy)
    Source code(tar.gz)
    Source code(zip)
    core-v4.0.0-RC1-javadoc.jar(1.87 MB)
    core-v4.0.0-RC1-sources.jar(2.44 MB)
    core-v4.0.0-RC1-test-fixtures.jar(97.32 KB)
    core-v4.0.0-RC1.jar(2.73 MB)
A simple Java Scheduler library with a minimal footprint and a straightforward API

Wisp Scheduler Wisp is a library for managing the execution of recurring Java jobs. It works like the Java class ScheduledThreadPoolExecutor, but it c

Coreoz 105 Dec 31, 2022
Cron utils for parsing, validations and human readable descriptions as well as date/time interoperability.

cron-utils We define crons. And support them. cron-utils is a Java library to define, parse, validate, migrate crons as well as get human readable des

jmrozanec 965 Dec 30, 2022
The simple, stupid batch framework for Java

Easy Batch The simple, stupid batch framework for Java™ Project status As of November 18, 2020, Easy Batch is in maintenance mode. This means only bug

Jeasy 571 Dec 29, 2022
MapDB provides concurrent Maps, Sets and Queues backed by disk storage or off-heap-memory. It is a fast and easy to use embedded Java database engine.

MapDB: database engine MapDB combines embedded database engine and Java collections. It is free under Apache 2 license. MapDB is flexible and can be u

Jan Kotek 4.6k Dec 30, 2022
MapDB provides concurrent Maps, Sets and Queues backed by disk storage or off-heap-memory. It is a fast and easy to use embedded Java database engine.

MapDB: database engine MapDB combines embedded database engine and Java collections. It is free under Apache 2 license. MapDB is flexible and can be u

Jan Kotek 4.6k Jan 1, 2023
Extremely simple and easy to use lucky blocks plugin!

SimpleLuckyBlocks plugin, the new fully customisable lucky blocks plugin Ever felt the need for a free, yet simple lucky blocks plugin? Well you've fo

Steven Zhu 4 Jun 8, 2022
vʌvr (formerly called Javaslang) is a non-commercial, non-profit object-functional library that runs with Java 8+. It aims to reduce the lines of code and increase code quality.

Vavr is an object-functional language extension to Java 8, which aims to reduce the lines of code and increase code quality. It provides persistent co

vavr 5.1k Jan 3, 2023
Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.

Themis provides strong, usable cryptography for busy people General purpose cryptographic library for storage and messaging for iOS (Swift, Obj-C), An

Cossack Labs 1.6k Dec 29, 2022
An easy-to-use wrapper for many storage systems.

Data Store An easy-to-use wrapper for redis' cached storage system. (support for more data types coming soon) Note: This project is unfinished, and th

Subham 4 Jul 17, 2022
A Slimefun4 addon that adds a new storage solution for mass and organised storage without harsh performance.

Networks is a Slimefun4 addon that brings a simple yet powerful item storage and movement network that works along side cargo. Network Grid / Crafting

null 17 Jan 7, 2023
MapNeat is a JVM library written in Kotlin that provides an easy to use DSL (Domain Specific Language) for transforming JSON to JSON, XML to JSON, POJO to JSON in a declarative way.

MapNeat is a JVM library written in Kotlin that provides an easy to use DSL (Domain Specific Language) for transforming JSON to JSON, XML to JSON, POJ

Andrei Ciobanu 59 Sep 17, 2022
Dagger is an easy-to-use, configuration over code, cloud-native framework built on top of Apache Flink for stateful processing of real-time streaming data.

Dagger Dagger or Data Aggregator is an easy-to-use, configuration over code, cloud-native framework built on top of Apache Flink for stateful processi

Open DataOps Foundation 238 Dec 22, 2022
A game made in Javafx that includes animation, background music, and view leaderboards

A game made in Javafx that includes animation, background music, and view leaderboards. To keep the game alive, a player has to move the ball up/down by pressing the up/down arrow so that the ball only touches different rotating obstacles with the same color. ..

Bijendar Prasad 3 Nov 19, 2022
The open source CyborgFlow project is an out-of-the-box (OOTB) solution to perform load test on your online system.

CyborgFlow CyborgFlow provides an out-of-the-box (OOTB) solution to perform load test on your online system, powered by Apache APISIX, Apache SkyWalki

SphereEx 70 Nov 30, 2022
Android service daemon ,keep background service alive

安卓后台保活2021新姿势 适配华为大部分系列手机,vivo,OPPO 部分机型,小米的不支持,可见小米在对抗后台自保上做得最好 本项目原本是给某个公司合作开发的,最后给了对方SDK之后由于付款问题闹得很郁闷,想着这个代码拿在自己手上也没用,就发出来给大家参考参考。目前分析的结果来看,这个是全网目前

null 65 Nov 29, 2022
Accumulo backed time series database

Timely is a time series database application that provides secure access to time series data. Timely is written in Java and designed to work with Apac

National Security Agency 367 Oct 11, 2022
NPM Package - A react native component that let you to add a wavy background UI.

react-native-wavy-background A react native component that let you to add a wavy background UI. Installation npm install react-native-wavy-background

Shevon Soyza 10 Oct 19, 2022
Stream Processing and Complex Event Processing Engine

Siddhi Core Libraries Siddhi is a cloud native Streaming and Complex Event Processing engine that understands Streaming SQL queries in order to captur

Siddhi - Cloud Native Stream Processor 1.4k Jan 6, 2023