[
https://issues.apache.org/jira/browse/CXF-1217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544859
]
Gary Tully commented on CXF-1217:
---------------------------------
So I finally got to the root of this problem. It is a combination of keep-alive
and chunking and stream wrapping.
Keepalive is on by default and turned on in HTTPClient by default for http 1.1
responses. The keepalive check interval is 5 seconds so it there is a sleep in
the code, we don't end up reusing a keepalive connection and everything works.
In the BusShutdownTest there is no point to keepalive because the server goes
away after the first request so the socket is always in close_wait when the
client attempts to use it.
When the client gets a cached/keep-alive socket, the write succeeds and the
read response fails because the server side of the socket has been closed. The
retry logic in HttpClient attempts to close and reopen the connection to the
server and resend the request. This works unless chunking is on and the
original data has already been flushed/streamed out to the socket and is not
available for retransmission. With chunking we end up sending a empty body and
not getting much of a reply so we timeout. (I Have not traced exactly what gets
sent on the wire in this case but from the code it appears to just be the
header, no body to which we get a continue)
The last bit of the puzzle is
org.apache.cxf.transport.http.HTTPConduit.WrappedOutputStream.handleHeadersTrustCaching().
This code forces the early write of the headers which in the case of
streaming/chunking means they will be lost. I think the onset of these problems
must have coincided with the addition of handleHeadersTrustCaching?
The upshot of all this is that disabling chunking via config is a viable
workaround. The problem is on the client, not on the server. Adding the
following in cxf.xml and providing the config file name to createBus() does the
trick.
<beans xmlns="http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:http="http://cxf.apache.org/transports/http/configuration";
xsi:schemaLocation="
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd";>
<http:conduit name="*.http-conduit">
<http:client AllowChunking="false"/>
</http:conduit>
</beans>
Also, disabling keepAlive at the HTTPClient layer has the desired effect:
-Dhttp.keepAlive=false but we are back into system property land which should
be avoided for specific test cases.
I guess the obvious question now surrounds handleHeadersTrustCaching() with
chunking and keepalives and server closed sockets, do we expect this to work
and if so can we fix it?
> Address in use errors from attempt to repeatedly start and stop services
> ------------------------------------------------------------------------
>
> Key: CXF-1217
> URL: https://issues.apache.org/jira/browse/CXF-1217
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 2.1
> Environment: Any
> Reporter: Benson Margulies
> Assignee: willem Jiang
> Attachments: busShutdownTest.patch.txt, jetty6.1.6.patch
>
>
> Edit org.apache.cxf.javascript.JsHttpRequestTest to take out the
> @org.junit.Ignore from the test case that has one, and run from eclipse.
> Watch the logging traffic. Observe:
> WARNING: failed [EMAIL PROTECTED]
> java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind(Native Method)
> which eventually, as far as I can tell, turns into:
> INFO: doOpen POST http://localhost:8808/Greeter false
> Nov 18, 2007 10:07:08 PM org.apache.cxf.javascript.JsXMLHttpRequest
> communicate
> SEVERE: IO error reading response
> java.io.FileNotFoundException: http://localhost:8808/Greeter
> On the other hand, all is well in Eclipse.
> I will probably commit a workaround to this soon, so it would be good to move
> this muddle to its own test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
