You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Aida <ai...@gmail.com> on 2014/04/21 18:25:39 UTC
[Camel-Cxf] Camel Exchange not returned when SocketTimeoutException
happens
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.
Re: [Camel-Cxf] Camel Exchange not returned when
SocketTimeoutException happens
Posted by Aida <ai...@gmail.com>.
Hello,
I wanted to ask, if it's not too much trouble, if anyone could help me with
this issue or give any idea so I can advance in my research.
I think that the problem could be in Camel since the Exception arrives to
the Camel classes of the CXF component as the exception trace of my previous
message shows.
In the DefaultCxfBinding class, at the populateExchangeFromCxfResponse
method:
if (cxfMessage.getAttachments() != null &&
!(DataFormat.POJO.equals(dataFormat) && isXop)) {
// propagate attachments
for (Attachment attachment : cxfMessage.getAttachments()) {
camelExchange.getOut().addAttachment(attachment.getId(),
attachment.getDataHandler());
}
}
Is here where my exception is thrown (the web-service I consume returns an
attachment in its response), and then is propagated back. I have been
debugging in case I could clarify what the problem is but, with no luck.
Thanks in advance,
KR
Aida.
Aida wrote
> Hi,
>
> I confirm that the problem
*
> continues happening to me using the 2.13.0 version of Camel
*
> .
>
> Just for recall:
> *
*
> I'm calling Web Services using cxf endpoints
*
> *
*
> When a SocketTimeoutException happens there is no Exchange "coming back"
> to the route from the request to the WS was made
*
> *
*
> I have checked that the behaviour is the same for Camel 2.11.2, 2.12.0 and
> 2.13.0
*
> * The example of this was:
> 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 also have checked that:
> 1.
*
> When the connection is not securized, there is no problem when a
> SocketTimeoutException happens, and the message "comes back" to the route
> to continue the routing
*
> 2.
*
> When the connection is securized, the problem persists (if I force a
> SocketTimeoutException to happen there is no message returning to the
> Camel route)
*
>
>
> Extra information:
> * For the cxf endpoints I have an httpConduit configured like:
>
> <http:conduit name="{http://... .http-conduit">
>
> <http:tlsClientParameters>
>
> <sec:trustManagers>
>
> <sec:keyStore type="JKS" resource="ssl/certs/mytrust.jks" />
>
> </sec:trustManagers>
>
> <sec:keyManagers keyPassword="${keystore.password.my}">
>
> <sec:keyStore type="JKS" password="${keystore.password.my}"
> resource="${keystore.file.path.my}" />
>
> </sec:keyManagers>
>
>
> </http:tlsClientParameters>
>
> </http:conduit>
>
>
> * An example of the exception message is this one (and apart from this
> message I have no more information in the log, such as information about
> the Exchange being processed in the route like the information logged
> since 2.12.X branch when an exception happens in a route):
>
> java.lang.RuntimeException: java.net.SocketTimeoutException: Read timed
> out
> at
> org.apache.cxf.attachment.LazyAttachmentCollection$1.hasNext(LazyAttachmentCollection.java:103)
> at
> org.apache.camel.component.cxf.DefaultCxfBinding.populateExchangeFromCxfResponse(DefaultCxfBinding.java:176)
> at
> org.apache.camel.component.cxf.CxfClientCallback.handleException(CxfClientCallback.java:96)
> at
> org.apache.cxf.interceptor.ClientOutFaultObserver.onMessage(ClientOutFaultObserver.java:59)
> at
> org.apache.cxf.endpoint.ClientImpl$1.onMessage(ClientImpl.java:556)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$1.run(HTTPConduit.java:1138)
> at
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:428)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:353)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:129)
> at
> com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
> at
> com.sun.net.ssl.internal.ssl.InputRecord.readV3Record(InputRecord.java:405)
> at
> com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:360)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:830)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:787)
> at
> com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
> at
> sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:525)
> at
> sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:582)
> at
> sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:669)
> at java.io.FilterInputStream.read(FilterInputStream.java:116)
> at
> sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2668)
> at
> sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2663)
> at
> sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2652)
> at java.io.FilterInputStream.read(FilterInputStream.java:66)
> at java.io.PushbackInputStream.read(PushbackInputStream.java:122)
> at
> org.apache.cxf.attachment.AttachmentDeserializer.readNext(AttachmentDeserializer.java:177)
> at
> org.apache.cxf.attachment.LazyAttachmentCollection$1.hasNext(LazyAttachmentCollection.java:95)
> ... 10 more
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-Cxf-Camel-Exchange-not-returned-when-SocketTimeoutException-happens-tp5750398p5751532.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Camel-Cxf] Camel Exchange not returned when
SocketTimeoutException happens
Posted by Aida <ai...@gmail.com>.
Hi,
I confirm that the problem continues happening to me using the 2.13.0
version of Camel.
Just for recall:
* I'm calling Web Services using cxf endpoints
* When a SocketTimeoutException happens there is no Exchange "coming back"
to the route from the request to the WS was made
* I have checked that the behaviour is the same for Camel 2.11.2, 2.12.0
and 2.13.0
* The example of this was:
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 also have checked that:
1. When the connection is not securized, there is no problem when a
SocketTimeoutException happens, and the message "comes back" to the route to
continue the routing
2. When the connection is securized, the problem persists (if I force a
SocketTimeoutException to happen there is no message returning to the Camel
route)
Extra information:
* For the cxf endpoints I have an httpConduit configured like:
<http:conduit name="{http://... .http-conduit">
<http:tlsClientParameters>
<sec:trustManagers>
<sec:keyStore type="JKS" resource="ssl/certs/mytrust.jks" />
</sec:trustManagers>
<sec:keyManagers keyPassword="${keystore.password.my}">
<sec:keyStore type="JKS" password="${keystore.password.my}"
resource="${keystore.file.path.my}" />
</sec:keyManagers>
</http:tlsClientParameters>
</http:conduit>
* An example of the exception message is this one (and apart from this
message I have no more information in the log, such as information about the
Exchange being processed in the route like the information logged since
2.12.X branch when an exception happens in a route):
java.lang.RuntimeException: java.net.SocketTimeoutException: Read timed out
at
org.apache.cxf.attachment.LazyAttachmentCollection$1.hasNext(LazyAttachmentCollection.java:103)
at
org.apache.camel.component.cxf.DefaultCxfBinding.populateExchangeFromCxfResponse(DefaultCxfBinding.java:176)
at
org.apache.camel.component.cxf.CxfClientCallback.handleException(CxfClientCallback.java:96)
at
org.apache.cxf.interceptor.ClientOutFaultObserver.onMessage(ClientOutFaultObserver.java:59)
at org.apache.cxf.endpoint.ClientImpl$1.onMessage(ClientImpl.java:556)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$1.run(HTTPConduit.java:1138)
at
org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:428)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at
org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:353)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at
com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
at
com.sun.net.ssl.internal.ssl.InputRecord.readV3Record(InputRecord.java:405)
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:360)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:830)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:787)
at
com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
at
sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:525)
at
sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:582)
at
sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:669)
at java.io.FilterInputStream.read(FilterInputStream.java:116)
at
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2668)
at
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2663)
at
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2652)
at java.io.FilterInputStream.read(FilterInputStream.java:66)
at java.io.PushbackInputStream.read(PushbackInputStream.java:122)
at
org.apache.cxf.attachment.AttachmentDeserializer.readNext(AttachmentDeserializer.java:177)
at
org.apache.cxf.attachment.LazyAttachmentCollection$1.hasNext(LazyAttachmentCollection.java:95)
... 10 more
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-Cxf-Camel-Exchange-not-returned-when-SocketTimeoutException-happens-tp5750398p5750944.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Camel-Cxf] Camel Exchange not returned when
SocketTimeoutException happens
Posted by Aida <ai...@gmail.com>.
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.
Re: [Camel-Cxf] Camel Exchange not returned when
SocketTimeoutException happens
Posted by Willem Jiang <wi...@gmail.com>.
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@gmail.com) 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.
>
Re: [Camel-Cxf] Camel Exchange not returned when
SocketTimeoutException happens
Posted by Aida <ai...@gmail.com>.
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.
Re: [Camel-Cxf] Camel Exchange not returned when
SocketTimeoutException happens
Posted by Willem Jiang <wi...@gmail.com>.
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@gmail.com) 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.
>