Hi Hadrian and Raul, Thanks for the suggestions!
@Hadrian: You're absolutely correct, and it the sounds like the mechanism you describe would support our use case. I'll watch for something like that in Camel 3 :-) @Raul: We did consider it, and we do actually use those features (dynamic routing, recipient list DSL) in some of our routes, but before (mis)using them to make our configuration more dynamic, I figured it would be worth investigating why they're not baked into the "standard" configuration mechanism (the properties component). After some research, it seems like we could probably make this a reality by changing less than a dozen lines of code (not counting tests) [1, 2]. The simpler we keep our routes, and the less we deviate from "standard" Camel, the better :-) Take care, Daniel [1] https://issues.apache.org/jira/browse/CAMEL-5734 [2] https://issues.apache.org/jira/browse/CAMEL-5747 -----Original Message----- From: Raul Kripalani [mailto:r...@evosent.com] Sent: Thursday, October 25, 2012 9:21 PM To: dev@camel.apache.org Subject: Re: Camel cold restart via JMX Have you considered using the dynamic router or recipient list DSL to look up at runtime the value of the endpoints that could change? You could cache the properties and then "watch" the file for changes thereon. Or you could also expose via JMX an operation to invalidate the cache so that the next Exchange triggers loading the properties again. You can also apply this approach to populate headers (e.g. Email addresses as you mentioned). Take a look at the bean language. Does that help? Regards, Raúl. Sent from a mobile device On 26 Oct 2012 00:28, "Hadrian Zbarcea" <hzbar...@gmail.com> wrote: > 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 >>> >>> >>>
