JobRunr, an open source job scheduler library for Java, has significant updates that increase its performance and framework integrations.
You can use any existing method of Spring services to create a job without the need to implement an interface. A job can be a short- or long-running process, and it will be automatically offloaded to a background thread so that the current web request is not blocked.
A major update appeared late last year with JobRunr 4.0.0.
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 the job is not cacheable, this is displayed in the dashboard.
JobRequest and JobRequestHandler. These features let you create jobs using the command pattern and the command handler pattern. Thus, you can use objects instead of lambdas to create background jobs. More about this below.
Static method support. JobRunr can now create jobs using lambdas that reference static methods.
CPU allocation irregularities detection. JobRunr uses the network time protocol (NTP) and timeouts to detect if a BackgroundJobServer is still alive. This can create a problem if the JVM is spending too much time doing garbage collection or if a cloud service stalls out due to excessive resources being used by other processes. JobRunr now detects the stall and shows a warning in the dashboard because it can impact the cluster.
There are also enhancements to the integrations with Spring Boot, Micronaut, and Quarkus. Therefore, the order of parameters passed to JobRunr has changed. In the earlier versions, covered in the 2021 article, the lambda was the first specified parameter. As of JobRunr 4.0.0, the lambda is the last parameter in the list.
Using JobRequest and JobRequestHandler
A JobRequest follows the command and the command handler patterns. The code below adds a background job to the job queue using a JobRequest. The JobRequest can contain data; when the job is started, the JobRequest object will be provided to the run method of the JobRequestHandler.
public class MyJobRequest implements JobRequest {
private UUID id;
public MyJobRequest(UUID id) {
this.id = id;
}
@Override
public Class<MyJobRequestHandler> getJobRequestHandler() {
return MyJobRequestHandler.class;
}
public UUID getId() {
return id;
}
}
JobId jobId = BackgroundJobRequest.enqueue(new MyJobRequest(id));
When you use a JobRequest to create jobs, note that the JobRequest itself is nothing more than a data transfer object; you should not pass services or beans with it. The smaller the JobRequest is, the better, because it will be serialized to JSON and stored in the StorageProvider.
Note that the JobRequest will be serialized and deserialized going to and from JSON. This also means it needs a default no-argument constructor and all fields must be capable of being serialized and deserialized.
A JobRequestHandler is a regular service—such as a Spring bean, a Micronaut singleton, or a Quarkus singleton—where you can inject other services, and it must be resolvable by the inversion of control (IoC) container.
When the job will be invoked, JobRunr asks the IoC container for the relevant JobRequestHandler, calls the run method of the instance, and passes the JobRequest as an argument. You can use all the data from the JobRequest inside the JobRequestHandler, as needed.
For example, the following JobRequestHandler handles all MyJobRequest calls. Because it is a regular bean, you can inject other services.
@Component
public class MyJobRequestHandler implements JobRequestHandler<MyJobRequest> {
@Inject
private SomeService someService; // you can inject other services (or constructor-injection)
@Override
@Job(name = "Some neat Job Display Name", retries = 2)
public void run(MyJobRequest jobRequest) {
// do your background work here
}
}
Source: oracle.com
Posts
0 comments:
Post a Comment