Add endpoints to improve the monitoring of a spring-boot-quartz application (see this)

Group:
* GET /actuator/quartzgroup: List all groups registered in quartz (group by type : trigger and job).

Job: * GET /actuator/quartzjob/: List all jobs registered in quartz (JobGroup and JobName). * GET /actuator/quartzjob/{group}: List all jobs for a given group (JobGroup and JobName). * GET /actuator/quartzjob/{group}/{name}: Get all information of a job (next fired date, data map etc...). * POST /actuator/quartzjob/{group}/{name}: Pause / Resume a job. * DELETE /actuator/quartzjob/{group}/{name}: Delete a job from the scheduler.

Trigger: * GET /actuator/quartztrigger/: List all triggers registered in quartz (Group and Name). * GET /actuator/quartztrigger/{group}: List all triggers for a given group (Group and Name). * GET /actuator/quartztrigger/{group}/{name}: Get all information of a trigger (next fired date, state of trigger etc...). * POST /actuator/quartztrigger/{group}/{name}: Pause / Resume a trigger. * DELETE /actuator/quartzjob/{group}/{name}: Delete the job link to a trigger from the scheduler.

Sample: Actuator

To test it and see the performance, you can use the branch on my fork : quartz-actuator-bench - A spring boot quartz application with 30000 jobs create at launch

Comment From: snicoll

See #10364

Comment From: snicoll

@JordanCouret thanks a lot for submitting your first PR to Spring Boot. This looks quite complete on surface but before digging in the details I'd like to better understand how this differs to what is being discussed in #10364.

Can you please share a short summary of the main differences?

Comment From: JordanCouret

I relied on this comment to move ahead with the subject of quartz actuator endpoint (Comment on 10364). The main differences are : • GET /quartzjobs : this API returns a short description of all jobs in the scheduler (one interaction with the Database). This is the main difference with the #10364 • POST / DELETE /quartzjobs : pause, resume or delete a job from the scheduler (one by one) • Add this API to access the trigger of the scheduler (/quartztrigger) • Add the API quartzgroup to retrieve the group details registered in the scheduler.

Comment From: wilkinsona

Thanks for your effort here, @JordanCouret, but I don't think we're ready to proceed one way or the other. @vpavic raised some performance concerns about my preferred arrangement for the endpoint. As described in a later comment on #10364, we need some performance data to allow us to proceed.

Edit: and now I read the opening comment again, I see that you have something that will let us measure the performance. Sorry, I missed that on first reading.

Comment From: wilkinsona

@JordanCouret Could you please update the demo project to use an external database? The concern that @vpavic raised was about a JDBC-based store and, as far as I can tell, your demo is using the in-memory store.

Comment From: JordanCouret

@wilkinsona I pushed a new version on the same branch with a postgres connection. It takes some times at start to create all jobs. But the actuator endpoint answer well. Edit: Please use docker-compose.yml in the demo folder to run the database

Comment From: jgoldhammer

Any progress here? I would love to see quartz support in Spring Boot...

Comment From: wilkinsona

@jgoldhammer Just to avoid any confusion, we already have Quartz support in the form of auto-configuration. This pull request is adding to that with an Actuator endpoint for dealing with quartz jobs and triggers. Unfortunately it's too late in the day for it to make it into 2.2. We'll look at it again when we're planning 2.3.

Comment From: jgoldhammer

Any progress here? I guess, quartz actuator support would be awesome! CC: @wilkinsona @snicoll

Comment From: dpolivaev

Any change on the issue status? Just curious how long people need to copy and paste code from https://dzone.com/articles/managing-quartz-using-spring-actuator due to lack of official implementation.

Comment From: wilkinsona

@JordanCouret Sorry it's taken so long to look at this in detail. Given the delay and the current climate, how much time and appetite do you have for refining your proposal?

As described in the comment that you linked to above, we'd like to see a single quartz endpoint that uses @Selector to provide access to jobs and triggers, rather than the separate endpoints that you have proposed here. If you tried that and it didn't work out, could you please explain why so that we can make an informed decision about which approach to use? There are also some other changes that are in order including the addition of Actuator API documentation and avoiding returning Quartz types from any operations.

Comment From: JordanCouret

@wilkinsona : Sorry for the delayed response, i pushed a new version. It contains the following endpoints :

Job: * GET /actuator/quartz/jobs: List all jobs registered in quartz (JobGroup and JobName). * GET /actuator/quartz/jobs/{group}: List all jobs for a given group (JobGroup and JobName). * GET /actuator/quartz/jobs/{group}/{name}: Get all information of a job (next fired date, data map etc...). * POST /actuator/quartz/jobs/{group}/{name}: Pause / Resume a job. * DELETE /actuator/quartz/jobs/{group}/{name}: Delete a job from the scheduler.

Trigger: * GET /actuator/quartz/triggers/: List all triggers registered in quartz (Group and Name). * GET /actuator/quartz/triggers/{group}: List all triggers for a given group (Group and Name). * GET /actuator/quartz/triggers/{group}/{name}: Get all information of a trigger (next fired date, state of trigger etc...). * POST /actuator/quartz/triggers/{group}/{name}: Pause / Resume a trigger. * DELETE /actuator/quartz/triggers/{group}/{name}: Delete a trigger from the scheduler.

I added some documentation according to your last comment and avoided to return Quartz's object.

Comment From: thePhil

I have created a PR waiting on @JordanCouret branch for fixing the last formatting issues.

Comment From: JordanCouret

Hi,

Thanks @thePhil for fixing the formatting issues. I certainly missed something in my IDE configuration.

Comment From: ArnoTurelinckx

Hey everyone, what's the current status on this?

Comment From: snicoll

@JordanCouret thanks very much for the PR and your follow-up on #10364. After analyzing this, I am not sure separating the triggers from the jobs make a lot of value at this point (and the representation of both in your PR are the same so the split in this PR is really artificial).

Regarding Andy's comment, it really was more a general thought on where the endpoint can go forward. Our plan was to first offer a read-only endpoint and then see how we can generally improve it to eventually add more options.

I think the original PR is closer to where we want to go for a first draft so I am going to close this one now but please keep the code around as we may want to revisit this at some point. Thanks again.