Hi Another update on this,

after taking a closer look on the system I fear I have the following issue:

Client calling on Server a is waiting for a response while Client 11 is
starting a new Call on Server k which rests the client waiting for response
of server a.
To me it seems possible that the clients seem to share the connections even
though the calls are within concurrent consumers.
Does it make sense, could this be my problem?
And if so, how do I get around it?

Thanx again, Achim


2011/11/8 Achim Nierbeck <bcanh...@googlemail.com>

> Hi all,
>
> Using Camel 2.8.1 with CXF 2.4.0
> I have a strange behaviour/issue with consuming Webservices with a cxf
> client.
>
> My Route has a configured CXF Endpoint
>
> <!-- CXF config -->
> <cxf:cxfEndpoint id="productionServer"
>  serviceClass="testme.Service"
> endpointName="s:Service" serviceName="s:ProductionService"
>  wsdlURL="classpath:/wsdl/_1.wsdl" xmlns:s="http://tempuri.org/";
> xmlns:a="http://schemas.microsoft.com/2003/10/Serialization/Arrays";
>  xmlns:i="http://www.w3.org/2001/XMLSchema-instance";>
> <cxf:properties>
>  <entry key="dataFormat" value="POJO" />
> </cxf:properties>
>  <cxf:outInterceptors>
> <ref bean="loggingOutInterceptor" />
>  </cxf:outInterceptors>
> </cxf:cxfEndpoint>
>
>
> and a SEDA Route like this
>
> <camel:route id="dummyTest">
>       <camel:from="seda:start?concurrentConsumers=20" />
>       <camel:setHeader headerName="operationNamespace">
>              <camel:constant>http://somenamespace/</camel:constant>
>        </camel:setHeader>
>        <camel:setHeader headerName="RequestContext">
>              <camel:mvel>[org.apache.cxf.message.Message.ENDPOINT_ADDRESS
> : headers.remoteAdress]</camel:mvel>
>         </camel:setHeader>
>        <camel:setHeader headerName="operationName">
>                 <camel:constant>ComputeSomething</camel:constant>
>        </camel:setHeader>
>        <camel:setBody>
>                 <camel:mvel>[]</camel:mvel>
>         </camel:setBody>
>        <camel:to uri="cxf:bean:productionServer" />
> </camel:route>
>
>
> If this seda route is "called" 3 times, all with different IPs, everything
> is fine, if there are more connections like 11,
> 8 of those connections are closed in a random order. With a
> SocketException.
>
> CaughtExceptionType:java.net.SocketException,
> CaughtExceptionMessage:Connection reset,
> StackTrace:java.net.SocketException: Connection reset
>  at java.net.SocketInputStream.read(SocketInputStream.java:168)
> 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.HttpClient.parseHTTPHeader(HttpClient.java:687)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
>  at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195)
>  at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1527)
>  at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$1.run(HTTPConduit.java:1490)
> at
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:334)
>  at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>  at java.lang.Thread.run(Thread.java:662)
>
> The Camel route is running inside a Tomcat which also serves another
> Frontend application on a Windows Server 2003.
> So right now my speculation is that this might be caused by the underlying
> OS.
> I'm thankful for any idea giving me the right direction :)
>
>
> Thanx in advance, Achim
>
>
>


-- 
--
*Achim Nierbeck*


Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>  Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>

Reply via email to