camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aida <ai.d...@gmail.com>
Subject Re: [Camel-Cxf] Camel Exchange not returned when SocketTimeoutException happens
Date Tue, 22 Apr 2014 15:10:54 GMT
Hi Willem,

Thank you very much for your response.

I'm trying to upgrade my version of Camel to 2.13.0 in order to check if I
have the same problem in the last release, as you told me, but I found an
obstacle.

>From Apache Camel 2.12.0, the ManagementStrategyFactory (that initializes
the DefaultManagementAgent of the CamelContext) doesn´t initialize the
ManagementStrategy service.

Before 2.12.0 (line 37 aprox):

	    ...
	    try {
		answer = new ManagedManagementStrategy(context, new
DefaultManagementAgent(context));
                // must start it to ensure JMX works and can load needed
Spring JARs
                ServiceHelper.startService(answer);
                // prefer to have it at first strategy
                context.getLifecycleStrategies().add(0, new
DefaultManagementLifecycleStrategy(context));
                log.info("JMX enabled.");
            } catch (Exception e) {
		...

		
And from 2.12.0 (line 37 aprox):
		..
		 try {
                answer = new ManagedManagementStrategy(context, new
DefaultManagementAgent(context));

                // must add management lifecycle strategy
                context.getLifecycleStrategies().add(0, new
DefaultManagementLifecycleStrategy(context));

            } catch (Exception e) {
		...
		
		
		
My problem is that I'm registering MBeans on my configureRoute() methods, in
order to register the ExecutorService(s) used in my RouteBuilders:

	@Override
	public void configureRoute() {
		//Threadpool executor with the default pool size
		ThreadPoolExecutorWrapper executeOperationsBatchExecutorService = new
ThreadPoolExecutorWrapper(ROUTE_NAME);
		try {
		
getContext().getManagementStrategy().getManagementAgent().register(executeOperationsBatchExecutorService,
executeOperationsBatchExecutorService.getMBeanName());
		} catch (JMException e) {
			throw new RuntimeCamelException("It was impossible to register the MBean
with name: " +
executeOperationsBatchExecutorService.getMBeanName().getCanonicalName(), e);
		}
	    ...
	}
		
As from 2.12.0 the service is not started, in the DefaultManagementAgent,
the MBeanServer is null, so a NullpointerException is thrown (and I cannot
test my issue with Apache Camel 2.13.0).

I have tried with the configurations described in [1] (configuring a
jmxAgent with Spring) to see if this way the initialization happened before
but with no luck.

For JUnit tests (where a nullpointerException is also launched) if i set
useJmx() returning true and I force the initialization of the agent like
this:

context.getManagementStrategy().getManagementAgent().start();

It works fine, but I'm not able to solve it in a "real" environment.


Any help with this would be really appreciated, so I can test this scenary
with the last Camel version to see if I can reproduce it.

Thanks in advance,

KR,

  Aida.

[1] http://camel.apache.org/camel-jmx.html



Willem.Jiang wrote
> I just wrote a simple test[1] in camel trunk(camel-2.14-SNAPSHOT) to
> reproduce the error.
> But I cannot reproduce the error.
> 
> Can you 
*
> try to use last released camel-2.13.0 for verification
*
> ?
> 
> [1]https://git-wip-us.apache.org/repos/asf?p=camel.git;a=commit;h=fdc3b321
> 
> --  
> Willem Jiang
> 
> Red Hat, Inc.
> Web: http://www.redhat.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.iteye.com (Chinese)
> Twitter: willemjiang  
> Weibo: 姜宁willem
> 
> 
> 
> On April 22, 2014 at 12:26:07 AM, Aida (

> ai.desu@

> ) wrote:
>> Hi,
>>  
>> I'm working with the cxf component in order to consume from JAX-WS
>> services,
>> and everything works like a charm, but I'm having trouble when a
>> SocketTimeoutException happens. In this case, I have no Camel Exchange
>> coming back from the endpoint.
>>  
>> Example:
>>  
>> from(startEndpoint)
>> .doTry()
>> .to(cxfEndpoint)
>> .doCatch(Throwable.class)
>> .log("Hey, an exception happened")
>> .bean(myExceptionHandler)
>> .end();
>>  
>> When a Exception that is not a SocketTimeoutException happens, then the
>> message moves into the "doCatch" block as expected and the message
>> continues
>> the routing. Otherwise, when a SocketTimeoutException occurs doesn´t, as
>> if
>> the Camel Exchange would have disappeared or a thread would have been
>> killed.
>>  
>> I have been debugging and when the SocketTimeoutException happens, the
>> Camel
>> Exchange is, at first, populated from cxf response:
>>  
>> ClientOutFaultObserver.onMessage -> CxfClientCallback.handleException ->
>> DefaultCxfBinding.populateExchangeFromCxfResponse
>>  
>> But despite off my debugging I lose the track and I'm not able to see
>> where
>> exactly the message is lost, but I see that the message achieves the cxf
>> component, so I don´t know exactly if it´s a Camel Cxf component "issue"
>> or
>> a CXF API one.
>>  
>> I wanted to ask if anyone knows if this is the expected behaviour for
>> this
>> kind of exception (maybe for an InterruptedIOException it is), or if I
>> should expect the message to be retrieved.
>>  
>> Extra information:
>> - The SocketTimeoutException happens after establishing the connection,
>> when the socket is ready to read
>> - If, for example, an UnknownHostException happens, I have a Camel
>> Exchange
>> in the "doCatch" block
>> - The CXF endpoints are configured using Spring and use SSL (certificate
>> authentication)
>> - Apache Camel version 2.11.2
>>  
>> Thanks in advance.
>>  
>> KR,
>>  
>> Aida.
>>  
>>  
>>  
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Camel-Cxf-Camel-Exchange-not-returned-when-SocketTimeoutException-happens-tp5750398.html
 
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>





--
View this message in context: http://camel.465427.n5.nabble.com/Camel-Cxf-Camel-Exchange-not-returned-when-SocketTimeoutException-happens-tp5750398p5750438.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Mime
View raw message