[
https://issues.apache.org/jira/browse/HTTPCLIENT-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453146#comment-13453146
]
Richard DiCroce commented on HTTPCLIENT-1233:
---------------------------------------------
The log file totals about 90MB and the upload limit for attached files is 10MB,
so instead, I'm attaching the debug outputs for a single request. I think I've
spotted the problem. After a 200 is received, the connection is properly placed
back into the pool:
[DEBUG] DefaultHttpClient - Connection can be kept alive indefinitely
[DEBUG] PoolingClientConnectionManager - Connection [id: 0][route:
{}->http://localhost:8080] can be kept alive indefinitely
[DEBUG] PoolingClientConnectionManager - Connection released: [id: 0][route:
{}->http://localhost:8080][total kept alive: 1; route allocated: 1 of 100;
total allocated: 1 of 200]
But after a 204 is received, it is not:
[DEBUG] PoolingClientConnectionManager - Connection [id: 0][route:
{}->http://localhost:8080] can be kept alive for 9223372036854775807
MILLISECONDS
[DEBUG] DefaultClientConnection - Connection 0.0.0.0:57560<->127.0.0.1:8080
closed
[DEBUG] PoolingClientConnectionManager - Connection released: [id: 0][route:
{}->http://localhost:8080][total kept alive: 0; route allocated: 0 of 100;
total allocated: 0 of 200]
Of course, the OS has to keep the connection open for a while after it is
"closed" to satisfy the requirements of TCP, and the load tester is sending
messages so quickly that these "closed" connections aren't going away fast
enough.
> Massive connection leak for 204 responses
> -----------------------------------------
>
> Key: HTTPCLIENT-1233
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1233
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 4.2.1
> Reporter: Richard DiCroce
> Attachments: 200_debug.txt, 204_debug.txt
>
>
> I'm using the fluent API as part of a small Java application to load test a
> web service that I'm working on. Some endpoints in this web service consume
> data and don't return any data to the client. Server-side, I'm using JAX-RS
> (specifically, RESTEasy), which returns a 204 No Content response when an
> endpoint method returns void.
> I'm not sure if the leak is in HttpClient or in the way the fluent API wraps
> it, but connections for which a 204 response is received are never
> terminated. As a result, more and more connections are created, until about
> 16,000 messages have been sent, at which point the OS won't allow any more
> connections to be created and the load tester dies with this exception:
> Caused by: java.net.SocketException: No buffer space available (maximum
> connections reached?): connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.SocksSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at
> org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127)
> at
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:640)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
> at org.apache.http.client.fluent.Request.execute(Request.java:145)
> at
> com.lapis.cerberus.rest.impl.client.ApacheRestService.sendRequest(ApacheRestService.java:128)
> ... 2 more
> If I force the endpoint to instead return a 200 OK response, this problem
> does not occur. From my end, the only other noticeable difference is that
> Response.returnResponse().getEntity() returns null for a 204 response,
> whereas it is non-null for a 200 response (although
> HttpEntity.getContentLength() returns zero).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
