Hi Claus,

is it necessary to have a resume operation? I would propose to have only the start operation that can be called from stopped and from suspended state. Also I propose to allow the suspend command from stop to bring the route in a state where it can start faster.

My proposed changes would allow to call any method from almost any state which makes the model easier to use and understand.

Greetings

Christian


Am 02.08.2010 08:35, schrieb Claus Ibsen:
Hi

I am working a bit on improving the lifecycle and management of routes in Camel.

The bigger goal is to support suspension of routes / camel. For
example you can press suspend on CamelContext mbean and have it
temporary suspend all routes.
Then you can resume again by pressing resume, and the suspended routes
will be resumed. For example if there is a problem and you need to
just suspend Camel.
BTW Camel will only resume the routes which was suspended. So if you
have manually stopped a route beforehand, this route will remain
stopped.

Also we introduce management of routes so you can suspend an
individual route as well.
There will be a change in behavior of the stop route operation in JMX.
Previously it would force stop a route, disregarding any in flight
exchanges.
Now the stop operation will use the graceful shutdown feature in Camel
and stop the route more reliable. If you want to force stop a route
you can pass in a timeout value, such as a couple of seconds. Which
triggers Camel to force stopping when the timeout was hit.

Routes can now support suspension, which is done by letting it's
consumer implement the SuspendableService interface. This gives those
consumers a fine grained control of suspension.
There are doSuspend, doResume methods readily available from
ServiceSupport. Which means the DefaultConsumer got it already. For
example the camel-jms component leverages this in its JmsConsumer.
This allows it more gently to suspend listening on a JMS queue.

Likewise camel-jetty consumer will return HTTP status 503 if its
suspended. If you stop it, then it will unbind the port listener. So
suspension is much quicker and gentler to use if you just temporary
need the route to be inactive.

Component writers is encouraged to support this if its possible. For
example this would be great for the many HTTP based consumers to
support.

On the same time we are fixing the JMX management to always list all
routes (also if they have been configured with autoStartup=false).
This allows you actually to manually start those routes from JMX :).

And there will be a shutdown operation for routes. It's to be used for
removing a route from management. The idea would be for you have to
stop the route first before you can shutdown and remove the route.
Maybe we should rename the shutdown operation name to remove?

You can see some background information here:
https://cwiki.apache.org/confluence/display/CAMEL/Lifecycle

Which has a diagram of the lifecycle states.


Any thoughts?



--
----
http://www.liquid-reality.de

Reply via email to