Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of hzbarcea@gmail.com designates
 209.85.160.173 as permitted sender)
Message-ID: <5089CAFE.9020400@gmail.com>
Date: Thu, 25 Oct 2012 19:27:58 -0400
From: Hadrian Zbarcea <hzbarcea@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: dev@camel.apache.org
Subject: Re: Camel cold restart via JMX
References: 
 <61664300480FCF4EAC0C1A5C431A6FCC3599185B@atl-exch2.DHLGLOBALMAIL.CORP>
 <50892AED.3040808@gmail.com>
 <61664300480FCF4EAC0C1A5C431A6FCC35AC98C2@atl-exch2.DHLGLOBALMAIL.CORP>
In-Reply-To: 
 <61664300480FCF4EAC0C1A5C431A6FCC35AC98C2@atl-exch2.DHLGLOBALMAIL.CORP>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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:hzbarcea@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
>>
>>