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
>
