I have the app on top of Quarkus framework. The main functionality of the app – simple REST API for scheduling some tasks (now it just posts some message to the log).
Scheduling functionality I implemented with Quartz framework and in common it looks like when the app get POST request for scheduling a new event it does two things:
- save entity from the request to the database;
- schedule Quartz job on mentioned in JSON date and time.
Also for case when the application just starts I created method which take all entities from database and schedule Quartz jobs for them.
But when I tried to build native image for that application using GraalVM I faced with such exception:
instances of sun.security.provider.NativePRNG are allowed in the image
heap as this class should be initialized at image runtime.
Fast search in Google gave me closed issue in GraalVM Github repo which say, that Quartz use RMI’s ObjID with run-time initialization. Due to that Quartz couldn’t be used in applications where is required native image compilation by GraalVM.
So does Quarkus scheduler provides abilities to schedule jobs right in Java code (something like in my implementation with Quartz)? In all examples and pieces of code I found I could see only pretty simple usage of @Scheduled annotation on methods (like in official guide). Or maybe there are any other alternative tools for scheduling tasks in Java that works with native image compilation?
So Quarkus Quartz extension (built on top of
quarkus-scheduler) does support GraalVM native images. The truth is that the API does not support programmatic scheduling and it’s not possible to access the underlying Quartz
Scheduler instance. I’ve created https://github.com/quarkusio/quarkus/issues/7246 to address the latter issue.
So does Quarkus scheduler provides abilities to schedule jobs right in Java code…
Maybe off topic, but just to let you know that you might encounter weird scheduling problems when running your app in a (Docker) container, since the timezone in the container might be different than your local timezone. So the scheduler might fight fire at a totally diff time than you had configured.
To fix this I had to add the following lines in my Dockerfile:
# set the correct timezone RUN apk add --no-cache tzdata ENV TZ=Europe/Amsterdam <---your timezone RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
Just my 2 cents.