cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-1217) Address in use errors from attempt to repeatedly start and stop services
Date Thu, 22 Nov 2007 18:16:43 GMT

    [ 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 Server@1174031
> 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.


Mime
View raw message