camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicky Sandhu <nickysan...@hotmail.com>
Subject Re: Monitoring and management of Camel
Date Fri, 08 Jun 2007 15:56:42 GMT


James.Strachan wrote:
> 
> Thanks for a great email Nicky...
> 
Thanks for the quick reply

James.Strachan wrote:
> 
> Would that do the trick? Or were you thinking of some kinda
> uber-registry thats Camel specific? Another option is that each
> CamelContext exposes itself in JMX...
> 
JMX would be best. Lest not blur thy Camel's objective.


James.Strachan wrote:
> 
> Absolutely!
> 
> We just need to expose the add/remove routes API to the MBeans (see
> above). You can already add a Route to a CamelContext whenever
> required.
> 

Perfect! We are on the same page. 

I was thinking about safe stops and starts of route. In other words if a
route is added or modified in a running context do existing instances of
route processing finish before the change is introduced. Similar issue when
stopping/removing a route.


James.Strachan wrote:
> 
> In what way were you thinking? Updating the Spring XML? Or reading the
> rules from a database?
> 
Something like that. The issue here is that JMX allows updating of routes
dynamically on a running system. This change should be persistent or else
restarts of the JVM would cause a loss of the change. 

Maybe it is possible to update a running context's routes/endpoints simply
by forcing a reload of Spring XML? Is that possible?

Again its about keeping the effect of two change interfaces (JMX and Spring
XML) in sync. How would you implement ??? thats a decision that you are more
qualified to make than me.


James.Strachan wrote:
> 
> We support a pluggable ErrorHandler right now which you can specify on
> a CamelContext, a Route or part of a route/pipeline which allows you
> to do things like dead letter channel stuff, or notifying some
> component of all failures out of band to the retries etc etc.
> http://activemq.apache.org/camel/error-handler.html
> 
> Would that do, or is there something else you had in mind?
> 

That is a good start. 

How about being able to save the state of the route in such a way that it
can be restarted from the failure point or postmortemed? As I can't even
translate this vision into requirements for Camel I'll give you the vision. 

The vision is that Camel is a pseudo language for gluing components together
using routes and endpoints. This means that there should be some support of
runtime debugging of this language. 

Of course we may not have call stacks anymore but there is still an
execution state that is currently not visible.


James.Strachan wrote:
> 
> Lots of this I was hoping we could sit on top of just Spring or Spring
> + OSGi or deploy Camel inside JBI (ServiceMix) as a JBI component.
> i.e. so Camel doesn't have to do any container level things; it just
> works with containers like servlet engines, Spring, OSGi and JBI. But
> 
Agree whole heartedly. JBI just needs to catch up to where OSGi already is.

-- 
View this message in context: http://www.nabble.com/Monitoring-and-management-of-Camel-tf3886171s22882.html#a11029197
Sent from the Camel - Users mailing list archive at Nabble.com.


Mime
View raw message