Thanks Daniel. Comments inline.
Hadrian
On 10/25/2012 04:52 PM, Daniel Gredler wrote:
Hi Hadrian,
The description from my first email is out of date (see the later
emails), however here's our specific scenario:
We have a user-facing application deployed to a JEE container that
contains an embedded Camel instance to help us do some async system
integration behind the scenes. We don't want to split the application
into two EARs so that we can keep builds / versioning / release process
as simple as possible.
So far so good.
However, we occasionally have to update the Camel configuration (e.g.
FTP host name change, or recipient email address change). Most of the
relevant Camel configuration is done via properties files and
PropertiesComponent (we actually use a custom subclass that allows us to
dynamically contribute properties file locations from different modules
based on runtime discovery without having to know the paths at compile
time, but that's a slightly different topic).
Fair enough.
The rub is that we don't want to have to schedule user-visible downtime
of the application just to get Camel to pick up some properties file
changes; the Camel cold restart allows us to do this (maybe?) without
bringing down the whole app or the app server.
Now this is what I suspected. What you really want is not to restart
camel, but reconfigure context/endpoints/routes at runtime. You know
that a context restart would do, so you were thinking about using the
side effect of that. Am I correct?
Normally, this would be done via a control channel, but that's another
thing missing from Camel that will hopefully be addressed in 3.0.
Services with a control channel could receive messages meant to
reconfigure the endpoint (if possible) at runtime, without restarting
the context (or other messages, documented by the component).
We do all of our Camel management and monitoring via JMX, which is why
the lack of support for cold restart via JMX came up.
Unfortunately it seems that the properties do not get reloaded on cold
restart. However, looking at the code, I think there's a good chance
that it's a bug in Camel and not by design... but I'll follow up on that
in the separate thread where Claus and Preben are discussing this topic
exactly :-)
Take care,
Daniel
-----Original Message-----
From: Hadrian Zbarcea [mailto:hzbar...@gmail.com]
Sent: Thursday, October 25, 2012 8:05 AM
To: dev@camel.apache.org
Subject: Re: Camel cold restart via JMX
Could you please describe more your situation and why a cold restart
would be needed? There may be other better solutions for your problem.
Cheers,
Hadrian
On 10/19/2012 03:51 PM, Daniel Gredler wrote:
Hi guys,
I was thinking about creating a feature request, but it involves such
a
fundamental aspect of Camel that I thought I'd ask here first.
I have a situation where I'd like to do a cold restart on a Camel
context (context.stop(), and then context.start()). The catch is that
I
want to do this via JMX, and when the Camel context is stopped, the
JMX
service goes down and obviously I can't issue the start() request.
I was thinking that it would be nice to have a restart() method on the
Camel context (defined as the equivalent of stop + start), possibly
even
in the Service interface which defines the start() and stop() methods.
This would allow the Camel context to go down and come back up without
requiring a second start() request, which is nice when the start()
request is impossible.
Is it worth creating the feature request? Am I missing something that
obviates the need for such a feature? Or is the use case so narrow
that
it doesn't really make sense to add? Let me know what you think...
Take care,
Daniel
