Right, I think that would be the way to go. It should be possible to set that up using pure spring-dm stuff and camel.
On Fri, Aug 28, 2009 at 11:31, Charles Moulliard <[email protected]>wrote: > You are right, I completely forget that bundles are started asynchronously. > Nevertheless, I would prefer to have something running outside of the > camelcontext even if the job scheduler is developed/based on Camel > technology as we can have several camel context running in separate > bundles. > > Imagine that we define a "scheduler service" like this : > > <job id="A" scheduler="ref to quartz cron definition" > errorHandlerRef="reference to the error hnadler who will handle the > exception"> > <start ref="routeA"> // bean refering to a camel toute > <transacted> // can be used when we have transacted job (= routes) > <choose> > <when> > <simple>job succeed</simple> > <stop ref="routeA"/> > <to queue:job:succeed> // can be a queue component where job report > information will be send OR > <start ref=routeB/> > </when> > <when> > <simple>job fails</simple> > <to queue:job:fail> > </when> > ... > </job> > > > Remarks : > My hypothesis depends on the following assertions : > - CamelContexts must be exported/exposed as a blueprint/spring DM/... > services, > - Routes defines in camel context are visible, > - When the job is started, it will wait to receive from camel route a > return > parameter : fail or succeed. Maybe this return could be placed as a message > in the a scheduler queue that the job context is listening !! > - If the job does not receive fail or succeed, then it should be possible > to > stop it (though console, mbeans, ... > > Regards > > Charles Moulliard > Senior Enterprise Architect > Apache Camel Committer > > ***************************** > blog : http://cmoulliard.blogspot.com > > > On Fri, Aug 28, 2009 at 10:18 AM, Guillaume Nodet <[email protected]> > wrote: > > > While I think this is very valuable, my first impression is that > scheduling > > at the bundle level is not necesseraly a good idea. > > I would think this would be more suitable to do that at the camel route > > level. > > The CamelContext has features to start / stop routes already, so it > should > > be quite easy to implement a scheduler on top of that. > > > > For bundles, it can be valuable too, but the problem is that bundles can > be > > started asynchronously (when using spring-dm or blueprint) so having some > > kind of return value would be quite difficult. > > Actually, you could use camel itself to implement the scheduler and start > / > > stop other routes or bundles ? It could also handle a timeout I think > and > > send alerts ... Camel is quite powerful, so it sounds reasonable to use > it. > > > > Thoughts ? > > > > On Thu, Aug 27, 2009 at 09:45, Charles Moulliard <[email protected] > > >wrote: > > > > > Hi, > > > > > > Since a couple of days I try to find an easy way to handle "jobs" in > > Apache > > > Felix Karaf and Camel. In standard, Camel proposes a camel-timer and > > > camel-quartz components but they can only be used inside a camel route. > > By > > > the way, camel context or camel routes are not "schedulable" like it is > > > possible with Spring batch. So it is not possible to start a route at > > 9:00 > > > and stop it at 11:00 and to check if the route succeed or fails inside > a > > > OSGI server. OF course, if camel is packaged in java standalone > > application > > > or j2EE server, alternative exist. > > > > > > This is why I come with the following idea who could be very > interesting > > > for Apache Felix Karaf in term of enterprise added value. > > > > > > *Job Scheduler for starting and stopping bundles* > > > > > > With the help of a quartz configuration file, the kernel of Apache > Felix > > > Karaf can check which bundles have to be scheduled (like jobs) and > > > started/stopped. The bundle to be started could be a camel route, .... > > When > > > the bundle stops or if the thread is still running at the end of the > job, > > > this information must be returned to the job scheduler in order to > decide > > > what to do (wait and send an alert to administrator to decide what to > > do). > > > Another interesting feature could be to return fail / succeed to the > job > > > scheduler to keep trace of what happen during job execution. This > > > information could be also used to link jobs / bundles together as this > is > > a > > > feature that you have with tool like IBM Tivoli Manager where you can > > chain > > > jobs. > > > > > > Regards, > > > > > > Charles Moulliard > > > Senior Enterprise Architect > > > Apache Camel Committer > > > > > > ***************************** > > > blog : http://cmoulliard.blogspot.com > > > > > > > > > > > -- > > Cheers, > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > Open Source SOA > > http://fusesource.com > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
