Many people asked can they manage Quartz via JMX, and I am not sure why Quartz doc won’t even mention it. Yes you can enable JMX in quartz with the following in
org.quartz.scheduler.jmx.export = true
After this, you use standard JMX client such as
$JAVA_HOME/bin/jconsole to connect and manage remotely.
Option 2: RMI
Another way to manage quartz remotely is to enable RMI in Quartz. If you use this, you basically run one instance of Quartz as RMI server, and then you can create second Quartz instance as RMI client. These two can talk remotely via a TCP port.
For server scheduler instance, you want to add these in
org.quartz.scheduler.rmi.export = true org.quartz.scheduler.rmi.createRegistry = true org.quartz.scheduler.rmi.registryHost = localhost org.quartz.scheduler.rmi.registryPort = 1099 org.quartz.scheduler.rmi.serverPort = 1100
And for client scheduler instance, you want to add these in
org.quartz.scheduler.rmi.proxy = true org.quartz.scheduler.rmi.registryHost = localhost org.quartz.scheduler.rmi.registryPort = 1099
The RMI feature is mentioned in Quartz doc here. Quartz doesn’t have a client API, but use the same
org.quartz.Scheduler for both server and client. It’s just the configuration are different. By different configuration, you get very different behavior. For server, your scheduler is running all the jobs, while for client, it’s simply a proxy. Your client scheduler instance will not run any jobs! You must be really careful when shutting down client because it does allow you to bring down the server!
These configurations have been highlighted in the MySchedule project. If you run the webapp, you should see a screen like this demo, and you will see it provided many sample of quartz configurations with these remote managment config properties.
If configure with RMI option, you can actually still use MySchedule web UI to manage the Quartz as proxy. You can view and drill down jobs, and you can even stop or shutdown remote server!
Based on my experience, there is a down side of using Quartz RMI feature though. That is it creates a single point of failure. There is no fail over if your RMI server port is down!