We need to do some addition work to let clustered quartz endpoint share the same camel context id. I just created a JIRA[1] for it.
[1]https://issues.apache.org/jira/browse/CAMEL-7947 -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On October 28, 2014 at 1:56:35 PM, lakshmi.prashant (lakshmi.prash...@gmail.com) wrote: > We are setting the camel Context id in the blueprint xml and have deployed it > to the osgi environment. > > Eg: > > Then we get misfires when other VM's in the cluster try to do load balancing > of the trigger : > > No CamelContext could be found with name: *572-Quartz2_Mig_Test1* . > > Why is the osgi bundle id (572) being appended to the camelContext id to > generate the name? > If the OSGI bundle id is different for the deployed route bundle in the > different VM's, we are getting misfires when those VM's acquire the triggers > & read the job data from DB. > > We need a way in which the same name / key is used to store / look-up a > specific camel context / Timer route across VM's. > > a) In createScheduler() of QuartzComponent.java, the camelContext is stored > against the camelcontext name derived as above. > > b) Hence, whenever the derived camel context name is different in different > VM's (or) if the route bundle is re-deployed, the camel context stored in > the scheduler context (in memory) is different from the camel context stored > in DB as part of the Job Data map. > > c) This results in misfires due to ' No CamelContext could be found with > name: *572-Quartz2_Mig_Test1*' in the above 2 scenarios. > > Thanks, > Lakshmi > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Quartz-job-data-deletion-in-clustered-quartz2-tp5757508p5758166.html > > Sent from the Camel - Users mailing list archive at Nabble.com. >
