camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: Quartz job data deletion in clustered quartz2
Date Tue, 28 Oct 2014 08:25:43 GMT
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.


Willem Jiang

Red Hat, Inc.
Blog: (English) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem

On October 28, 2014 at 1:56:35 PM, lakshmi.prashant ( 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, 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:
> Sent from the Camel - Users mailing list archive at

View raw message