camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Monitoring and management of Camel
Date Fri, 08 Jun 2007 16:51:55 GMT
On 6/8/07, Nicky Sandhu <> wrote:
> James.Strachan wrote:
> >
> > Thanks for a great email Nicky...
> >
> Thanks for the quick reply

You're welcome - right back at you! :)

> 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.

Coolio :)

> 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.

Yeah. Typically each Route instance will have its own Producer and
Consumer objects; even if the same underlying Endpoint instance is
being used (often they can be different too); so for things like JMS
queues or files or whatnot, the new Route instance will take over on
the next 'message'. So when a route is stopped, it should do a
graceful shutdown so it would stop processing future messages at which
point the next route should kick in.

i.e. hopefully we'll have a safe transition; though we should write
some test cases to ensure that happens.

> 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.

Yeah; there's always been this debate with things like JMX; should
changes in JMX update the Java/XML code which booted the system up; or
should folks change whatever the configuration source is (Java/XML)
then reboot the route rulebase; or have a separate database of changes
applied after the code/XML files.

If each rule base were a deployment unit (whether a WAR, an OSGi
bundle or JBI deployment), its easy to just redeploy when things
change; whether its Java or XML.

It does get a tad more tricky when there's a separate configuration
persistence thingy triggered from JMX changes which overloads the
developer source (Java/XML). But its still possible. Definitely I can
see the use case for DB based rules with reload on change etc. (The
simplest would be to put XML docs in the DB :)

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

Yes! Spring supports auto-reloading if you change the XML file; this
is at the ApplicationContext level, so if the rules are specified in
Spring XML that would work. We could do similar things for scripts if
the rules were written in Groovy/Ruby fairly easily too.

> 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.

Gulp :). Am tempted to start with the simplest thing that could
possibly work; we edit the Java code / XML and reboot the context.
(Which could be the Spring ApplicationContext for example which
auto-detects the XML file changing).

> 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.
> >
> >
> > 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?

Sounds good - lemme just check I understand. So imagine a stream of
messages are received from endpoint E on a consumer; if a failure
occurs, so we retry X times for the first message that fails and if
that still breaks, then we just stop consuming all future messages &
wait for an operator to re-enable the consumer again? Thats certainly
an option (its actually much easier to implement than the
DeadLetterChannel approach :).

The 'Dead Letter Channel' approach is often popular as it means 1 bad
message doesn't stop your service; the bad messages are moved out of
the way to a separate queue or whatever, letting good messages
through. Though if the reason for the error is actually that no
messages can be processed; it'd be kinda nice if you could just pop
them back and shut down :). Certainly the Dead Letter approach can
break ordering when a failure occurs; so having a 'just stop after X
retries' is a good alternative I'd say.

Not sure of a good name for this policy though :) Any ideas?

> 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.

Definitely! :)

Its still early days but we need way more tools & help for diagnosing,
testing, simulating, monitoring, controlling etc.

e.g. for testing we've this so far...

(we need much more though)

> 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.

Agreed. Or to say that another way; JBI needs to adopt more OSGi
features (which it looks like might happen in JBI 2.0)


View raw message