camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "lakshmi.prashant" <lakshmi.prash...@gmail.com>
Subject Re: Quartz job data deletion in clustered quartz2
Date Tue, 28 Oct 2014 05:56:07 GMT
We are setting the camel Context id in the blueprint xml and have deployed it
to the osgi environment.

Eg: <camel:camelContext id="Quartz2_Mig_Test1" streamCache="true">

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.

Mime
View raw message