On Sun, Jul 25, 2010 at 6:18 PM, William Tam <email.w...@gmail.com> wrote:
> 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 just added a bit system out to this unit test and
DefaultTypeConverter. When running it, the type converted is only
access when its started.
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
CamelContext status: Started
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
CamelContext status: Stopped
public void testShutdownCompleteAllTasks() throws Exception {
System.out.println("CamelContext status: " + context.getStatus());
// give it 20 seconds to shutdown
context.getShutdownStrategy().setTimeout(20);
MockEndpoint bar = getMockEndpoint("mock:bar");
bar.expectedMinimumMessageCount(1);
assertMockEndpointsSatisfied();
int batch =
bar.getReceivedExchanges().get(0).getProperty(Exchange.BATCH_SIZE,
int.class);
// shutdown during processing
context.stop();
System.out.println("CamelContext status: " + context.getStatus());
// should route all 5
assertEquals("Should complete all messages", batch,
bar.getReceivedCounter());
}
And added this to DefaultTypeConverted
@SuppressWarnings("unchecked")
public Object doConvertTo(final Class type, final Exchange
exchange, final Object value) {
System.out.println("doConvertTo started: " + isStarted());
....
So it appears this test only access the DefaultTypeConverter when it's started.
> * 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.
>
> Cheers,
> William
>
>
> On 07/25/2010 02:46 AM, Claus Ibsen wrote:
>>
>> On Sun, Jul 25, 2010 at 5:55 AM, William Tam<email.w...@gmail.com> 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.
>>
>>
>>
>>
>>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
