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.

Reply via email to