JobRunr 5.0.0 Offre Un Meilleur Support Des Frameworks

Un peu plus de six mois après la sortie de JobRunr 4.0, Ronald Dehuysser, fondateur et principal développeur de JobRunr, a introduit JobRunr 5.0 pour offrir une prise en charge améliorée de Spring, Quarkus et Micronaut en fournissant une implémentation Spring Native, une configuration pour le nombre de tentatives par défaut, la sélection du type de base de données et le support de transactions. Désormais, les tâches peuvent être planifiées en fonction d'un intervalle et les expressions cron prennent en charge le dernier jour de la semaine et le dernier jour du mois.

JobRunr, un outil de planification de tâches dans la JVM open source gratuit pour une utilisation commerciale, permet le traitement en arrière-plan dans Java à l'aide d'un stockage persistant et prend en charge des solutions distribuées. La version professionnelle payante propose en outre des files d'attente, des batchs et un chaînage des jobs. Une bibliothèque Java générique est disponible ainsi que des solutions spécifiques pour Spring Boot, Micronaut et Quarkus.

Une source de données SQL, NoSQL ou InMemory doit être configurée pour utiliser JobRunr. Diverses options sont disponibles après la configuration afin d'exécuter des tâches en arrière-plan :

BackgroundJob.enqueue(() -> 
    System.out.println("Fire and forget, executed once."));
BackgroundJob.schedule(now().plusMinutes(1), () -> 
    System.out.println("Scheduled job, executed once"));
BackgroundJob.scheduleRecurrently(Cron.every30seconds(), () -> 
    System.out.println("Recurring job, executed every 30 seconds"));
BackgroundJob.enqueue(() -> jobRunrService.annotatedJob("retry"));

La dernière instruction utilise une méthode avec l'annotation @Job afin de réessayer le jon en cas d'exception :

@Job(name = "Example retry job", retries = 1)
public void annotatedJob(String variable) throws Exception {
	System.out.println("Annotated job " + variable);
	throw new Exception("Trigger retry");
}

L'exemple produit la sortie suivante, où la dernière ligne est répétée indéfiniment :

Recurring job, executed every 30 seconds
Fire and forget, executed once.
Annotated job retry
java.lang.Exception: Trigger retry
…
Annotated job retry
java.lang.Exception: Trigger retry
…
Recurring job, executed every 30 seconds
Scheduled job, executed once
Recurring job, executed every 30 seconds

Cette nouvelle version prend en charge Spring Native avec la dépendance jobrunr-spring-boot-native afin de créer et d'exécuter des applications avec GraalVM.

La planification des jobs est désormais également possible en utilisant une instance de la classe Duration en tant qu'intervalle de répétition :

BackgroundJob.scheduleRecurrently("recurring-job", Duration.ofSeconds(10), 
    () -> System.out.println("Recurring job"));

Changer les tâches récurrentes pour prendre en charge les intervalles est un changement radical ; toutes les tâches récurrentes et planifiées doivent être supprimées avant la mise à niveau vers JobRunr 5.0.

JobRunr dispose d'un tableau de bord Web en option qui, entre autres, affiche la journalisation. Le Mapped Diagnostic Context (MDC) de SLF4J permet l'utilisation des variables MDC dans la journalisation, comme l'utilisation du request correlationId :

@Job(name = "Example retry job %X{request.correlationId}", retries = 1)

La prise en charge des expressions Cron pour planifier des tâches le dernier jour de la semaine et le dernier jour du mois est désormais possible en plaçant un "L" dans les champs jour de la semaine ou jour du mois.

Il est désormais possible de spécifier le nombre de tentatives par défaut pour Spring Boot, Quarkus et Micronaut :

# Spring Boot
org.jobrunr.jobs.default-number-of-retries=42

# Quarkus
quarkus.jobs.default-number-of-retries=42

# Micronaut
jobrunr:
  jobs:
	default-number-of-retries:42

Lorsque plusieurs bases de données sont disponibles pour Spring Boot, Micronaut ou Quarkus, il est possible de configurer la base de données pour JobRunr en spécifiant le type de la base de données, par exemple sql :

# Spring Boot
org.jobrunr.database.type=sql 

# Quarkus
quarkus.jobrunr.database.type=sql

# Micronaut:
jobrunr:
  database:
	type:sql

L'API fluide de JobRunr prend désormais en charge les métriques Micrometer :

JobRunr.configure()
    .useMicroMeter(new JobRunrMicroMeterIntegration(meterRegistry));

Avec cette version, le tableau de bord a des balises méta noIndex et noFollow afin que les tableaux de bord accessibles au public sur Internet ne soient pas plus indexé par Google.

Les tâches récurrentes sont désormais mises en cache et rechargées une fois que le nombre de tâches change. Cela améliore les performances puisque les travaux ne sont plus rechargés à partir du StorageProvider à chaque fois que JobRunr recherche de nouveaux travaux.

Les changements de rupture dans cette version nécessiteront une mise à jour d'ElasticSearch et de toutes les dépendances de projet liées à JobRunr.

Les fonctionnalités suivantes ne sont disponibles que pour l'édition JobRunr Pro.

• Les transactions créées par Spring Boot Starter ou Micronaut Integration sont utilisés par JobRunr Pro.
• Le traitement instantané des jobs est désormais possible en tant que BackgroundJobServer qui ne nécessite plus un pollInterval d'au moins 5 secondes. Les beans Spring, Micronaut et Quarkus implémentant JobClientFilter ou JobServerFilter sont automatiquement enregistrés dans JobRunr en tant que Job Filters, permettant aux développeurs d'étendre les fonctionnalités existantes de JobRunr.
• Le JobRunr Pro Dashboard permet désormais de remettre en file d'attente ou de supprimer toutes les jobs ayant échoué une fois.
• Le JobScheduler peut désormais interroger les Job Results à partir de la base de données.

Lorsqu'on lui a demandé, en septembre 2021, ce que la communauté Java devrait savoir sur JobRunr, Ronald Dehuysser a déclaré à InfoQ :

Ronald Dehuysser : je voudrais souligner trois choses :

1. JobRunr fait de la magie avec ASM (qui est également utilisé par Spring, Hibernate et de nombreux autres frameworks) pour analyser la lambda du job. En utilisant ASM, j'ai vraiment beaucoup appris sur le bytecode de la JVM, ce qui n'est pas aussi difficile que je l'imaginais.
2. Comme JobRunr effectue une analyse du bytecode, il participe également au programme Oracle Quality Outreach. Cela signifie que JobRunr est testé par rapport aux prochaines versions de la JVM. Cela m'aide à m'assurer qu'il continuera à fonctionner sur les nouvelles versions de Java et aide également la communauté Java car les bugs dans la JVM elle-même sont détectés plus tôt.
3. Pour les utilisateurs qui ont besoin d'assistance ou de fonctionnalités supplémentaires, il existe également JobRunr Pro. Il s'appuie sur JobRunr et ajoute des fonctionnalités supplémentaires telles que des files d'attente avec différentes priorités (les jobs hautement prioritaires sont traités avant les jobs à faible priorité), le chaînage des jobs, les batchs atomiques et un meilleur tableau de bord qui ajoute des capacités de recherche.

Et, pour toute licence vendue, de nouveaux arbres sont prévus puisque 5 % des revenus sont reversés à teamtrees.

De plus amples détails sur la liste complète des modifications sont disponibles dans cet article de blog sur JobRunr 5.0.