3 Replies Latest reply on Sep 19, 2006 8:31 AM by Kerry Barnes

    quartz-ra.rar bug?

    Kerry Barnes Newbie

      I am running a clustered environment and need cron like functionality for some periodic maintenance we perform. I originally posted this under clustering but was recommended to try my hand here by Brian Stansberry.

      The examples in the EJB3 tutorial for using the quartz-ra.rar work picture perfect. That is until I actually cluster the machine up. Then instead of one job executing for the cluster it executes on each instance.

      Not a problem I discover the default Quartz implementation uses the Memory Job Store. I add a -D parameter so that it uses my own quartz.properties file which switches to a JDBC based Job Store.

      Next problem, the data sources don't load before the .rar files so I have to move the file to the deploy.last directory. Now my resource name is deploy.last#quartz-ra ... inconvenient, but still workable.

      Now the real problem. The JobStoreCMT file checks to make sure that if the JobDetail is marked as "volatile" the corresponding Trigger is also marked as "volatile." But, in the QuartzResourceAdapter.java the JobDetail is created with a volatility set to "true" during construction, but the CronTrigger doesn't supply that option at construction and the default setting is to have the volatility set to "false," which is never changed. A mismatch and a problem for me.

      So why isn't there a volatile entry in the QuartzActivationSpec so we can set this in the deployment, or at least have both Trigger and JobDetail match? I am assuming this is a bug, but JIRA said to start here first. So here I am.

      ------ Followup from original posting

      I added a volatile flag to the activation spec and it turns out Quartz tells you that if you are using a JDBC JobStore it is never volatile. So I then just set the JobDetail's volatility setting to false as well. Anyway with this change it appears (atleast with initial testing) to fix it.

        • 1. Re: quartz-ra.rar bug?
          Weston M. Price Master

          No reason this can't be added. File a JIRA request in the JCA service and I will take care of it.

          • 2. Re: quartz-ra.rar bug?
            Bill Burke Master

            put your MDB jar in the deploy-hasingleton directory. Then it will only be deployed on one machine in the cluster. If that node in the cluster goes down, the MDB will be deployed on another machine.

            BTW, I'm looking for somebody to help maintain this RAR. If you're interested, email me at

            bill@jboss.org with the subject "Quartz RAR"


            • 3. Re: quartz-ra.rar bug?
              Kerry Barnes Newbie

              Just now getting back to this, but Bill your suggestion I think would work best for me with one minor issue. It tries to deploy the jar file before JMS comes up. I get a javax.naming.NameNotFoundException: DefaultJmsProvider not bound.

              My other solution isn't much better. I had to move the quartz-ra.rar into the deploy.last directory to ensure the JDBC datasources got loaded first, but when the system restarts for what ever reason the ear deploying the bean in question can't find the deploy.last#quartz-ra.rar which makes sense since its deploying last.

              Is there anyway to set up dependancies for these so I can deply them when/where ever? Or does anyone have any other solutions for my "chicken or the egg" problem?