[
https://issues.apache.org/activemq/browse/CAMEL-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58370#action_58370
]
Jim Talbut commented on CAMEL-1954:
-----------------------------------
I have a need of something similar to this, though I was thinking of
implementing it outside of camel and then have it call camel routes as
necessary.
My requirements are for:
* A clustered quartz implementation.
* Jobs configured entirely from code (jobs will be added and removed at
runtime, so spring and other configuration files are of limited use for me).
> Proposition - add job scheduling feature to Camel
> -------------------------------------------------
>
> Key: CAMEL-1954
> URL: https://issues.apache.org/activemq/browse/CAMEL-1954
> 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.
