camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charles Moulliard (JIRA)" <>
Subject [jira] Closed: (CAMEL-1954) Proposition - add job scheduling feature to Camel
Date Fri, 19 Nov 2010 17:19:24 GMT


Charles Moulliard closed CAMEL-1954.

    Resolution: Fixed

I think that the new feature proposed in Camel 2.5 (
allows to schedule routes in camel using a scheduledRoute with Quartz. Even if the cron scheduler
is defined as parameter in the camel route, it allows to start/stop camel routes inside the
container where it is deployed. This simplifies the architecture and avoid to scan the bundles
to detect which one must be started and stopped. As a bundle can contain more than one camel
route, this is a better idea that the route policy associated with the route take care about
when the route must be started and stopped.

I propose to close my ticket

> Proposition - add job scheduling feature to Camel
> -------------------------------------------------
>                 Key: CAMEL-1954
>                 URL:
>             Project: Apache Camel
>          Issue Type: New Feature
>            Reporter: Charles Moulliard
>             Fix For: Future
> 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 / Camel 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.
> Idea about implementation
> Definition of the "scheduler service"  :
> <job id="A" scheduler="ref to quartz cron definition" errorHandlerRef="reference to
the error handler 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 
>      <start ref=routeB/> // new job (= route to start)
>   </when>
>   <when>
>      <simple>job fails</simple>
>      <to queue:job:fail>
>   </when>
>   ...
> </job>
> Remarks :
> My proposition 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 parameter could be placed as a message in the  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, ...

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message