Claus, thanks for your experiment.
On 07/25/2010 02:01 PM, Claus Ibsen wrote:
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.
