Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Message-ID: <3432576.8501290187164805.JavaMail.jira@thor>
Date: Fri, 19 Nov 2010 12:19:24 -0500 (EST)
From: "Charles Moulliard (JIRA)" <jira@apache.org>
To: camel-dev@activemq.apache.org
Subject: [jira] Closed: (CAMEL-1954) Proposition - add job scheduling
 feature to Camel
In-Reply-To: <1974539002.1251456313688.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/activemq/browse/CAMEL-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Moulliard closed CAMEL-1954.
------------------------------------

    Resolution: Fixed

I think that the new feature proposed in Camel 2.5 (http://camel.apache.org/routepolicy.html) 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: 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.