Thanks Willem, I was able to upgrade to 2.12.X branch and I still have the same problem (when a SocketTimeoutException happens, the routing of the message stops as it would have died).
I'm going to upgrade to 2.13.0 now to check it again. I have been testing more and I have found out that if I use exactly the same route but the service to consume is not "httpS", and I make a SocketTimeoutException happen there is no problem. However, when I use a service with SSL there is. (Maybe because of this, the unit test that you updated the other day worked) I'll inform you as soon as I test this with 2.13.0 release. Thanks in advance. KR, Aida. Willem.Jiang wrote > You can register the executeOperationsBatchExecutorService after camel > context is started. > Or you can register a custom ManagementLifecycleStrategy to manage the > lifecycle of your ExecutorService. > > -- > 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 11:11:24 PM, Aida ( > ai.desu@ > ) wrote: >> 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. >> -- View this message in context: http://camel.465427.n5.nabble.com/Camel-Cxf-Camel-Exchange-not-returned-when-SocketTimeoutException-happens-tp5750398p5750506.html Sent from the Camel - Users mailing list archive at Nabble.com.
