Description of problem: We have setup a cluster of Candlepins to use the same quartz database (mysql). When we launch Tomcat we get lots of stack traces similar to the following: Caused by: org.quartz.ObjectAlreadyExistsException: Unable to store Job with name: 'org.fedoraproject.candlepin.pinsett er.tasks.JobCleaner-1' and group: 'cron group', because one already exists with this identification. at org.quartz.impl.jdbcjobstore.JobStoreSupport.storeJob(JobStoreSupport.java:1093) at org.quartz.impl.jdbcjobstore.JobStoreSupport$3.execute(JobStoreSupport.java:1042) at org.quartz.impl.jdbcjobstore.JobStoreSupport$40.execute(JobStoreSupport.java:3670) at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3742) at org.quartz.impl.jdbcjobstore.JobStoreTX.executeInLock(JobStoreTX.java:90) at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInLock(JobStoreSupport.java:3666) at org.quartz.impl.jdbcjobstore.JobStoreSupport.storeJobAndTrigger(JobStoreSupport.java:1030) at org.quartz.core.QuartzScheduler.scheduleJob(QuartzScheduler.java:743) at org.quartz.impl.StdScheduler.scheduleJob(StdScheduler.java:243) at org.fedoraproject.candlepin.pinsetter.core.PinsetterKernel.scheduleJob(PinsetterKernel.java:274) ... 30 more Version-Release number of selected component (if applicable): candlepin-tomcat6-0.4.10-1.el6.noarch candlepin-0.4.10-1.el6.noarch Additional info: We talked with Jesus and a unique string needs to be added to the job names to work around this issue.
Any word on this?
fixed in master by 96cd75214f5699151f8567b13e5ac51264ac6c05
If quartz is in clustered mode, we shouldn't schedule any jobs. Doing so will cause a primary key violation on the second Candlepin node. The primary key for the table is: trigger name + trigger group. At first I believed it was that we weren't using unique enough names. The name collision was a red herring, the real problem is we don't want to create new jobs when in clustered mode. We now check to see if quartz is in clustered mode, and if there are any jobs already scheduled from another node. If not, we proceed to schedule the jobs as normal. Otherwise, we skip initialization of the jobs and join the existing cluster. Added getClassName(String) to Util. Updated unit tests.
Marking all community bugs modified or beyong as closed.