camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Tam <>
Subject Re: CamelContext restart issues CAMEL-2991
Date Sun, 25 Jul 2010 16:18:58 GMT
Hi Claus,

Thanks for your response.

* A ProcessorEndpoint is a hybrid between a Processor and a Endpoint.  
Therefore, SendProcessor does have a child if the destination is a 
ProcessorEndpoint.  Please take a look at 
RouteService.doGetChildServices().   You will see why Navigate can allow 
services associated with the ProcessEndpoint to be restarted.

* Yes, when I say 'type converter", I mean the DefaultTypeConverter.

* If I am not mistaken, ShutdownCompleteAllTasksTest is one example that 
the DefaultTypeConverter was accessed after the DefaultTypeConverter has 
been shutdown.

* I think you are against lazy loading of DefaultTypeConverter.  I am 
fine with that.  Then, we should really get rid of the lazy loading (in 
DefaultCamelContext.getTypeConverter).   That is really what the problem 
is because since it is a service, it gets stopped but the lazy loading 
does NOT re-start it.  (Maybe you just fixed it.  I haven't got a chance 
to try it.)   And believe me, having both (a Service and lazy load and 
start) is troublesome.

* IMO, If DefaultTypeConverter is a Service, it should not be usable 
(throw an error something) in the "stopped/not started" state when 
someone tries to use it.  Accessing a stopped DefaultTypeConverter is 
bad to say the least.  You don't get an error, you just get 
different/wrong result.


On 07/25/2010 02:46 AM, Claus Ibsen wrote:
> On Sun, Jul 25, 2010 at 5:55 AM, William Tam<>  wrote:
>> I observed some issue regarding restarting Camel Context that I want to
>> discuss.  The detail is in the CAMEL-2991.
>> * First off, any objection if SendProcessor implements Navigate?  It allows
>> services associated with the destination endpoint to be restarted.
> Why does navigate allow services associated with the destination to be
> restarted? Can you be more clear?
> The idea with navigate is for navigating the process graph.
> For example a Content Based Router, where you can navigate the
> when/otherwise processors etc.
> A SendProcessor doesn't have any "children" to navigate, and therefore
> should NOT be navigate.
>> * There is a problem with type converter not getting restarted because the
>> lazy instantiation won't start the services on the type converter unless the
>> type converter is newly created.  I notice (in a lot of unit tests) that it
>> is OK to use the type converter even if the CamelContext (its "container")
>> is stopped or has never been started.  If we want this behavior, then it
>> does not seem to make sense for type converter to be a service.  Type
>> converter could be used anytime including during the shutdown cycling.
>>   Since type converter has been added to the "servicesToClose" list, the type
>> converter could be stopped (unpredictably) when it is needed during the
>> shutdown cycle.  IMO, type converter probably should not be a service.
> I assume you mean the DefaultTypeConverter ?
> The DefaultTypeConverter must be a Service so CamelContext can start/stop it.
> It's important that it's the CamelContext that starts it on startup so
> all the type converters can be loaded up-front.
> Then there is no lazy loading.
> The problem with a lazy loading would be at runtime you can end up
> with concurrent access to the type converter registry
> and then multiple threads need to load the type converters, which
> enforces locking/synchronization. And you don't want this overhead
> at runtime. Hence the converters are loaded on startup.
> And to do this the DefaultTypeConverter MUST be a service so we have
> the start/stop methods.
> There is no strict check in several places of the code to check that a
> "service" is started before its being used.
> And therefore you can access code which has been stopped.
> Can you give an example of an unit test, which uses a type converter
> after CamelContext has been stopped?
> And when you say type converter you have to be more precise. There is
> a TypeConverterRegistry and then there are the 150+ individual type
> converters.
> The former is the DefaultTypeConverter which loads all the type
> converters. The latter is most often not a service because they are
> @Converter scanned.

View raw message