[
https://issues.apache.org/jira/browse/HTTPCLIENT-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski updated HTTPCLIENT-1233:
------------------------------------------
Fix Version/s: 4.2.2
Summary: 204 response causes unnecessary termination of re-usable
connection (was: Massive connection leak for 204 responses)
Richard,
It is not HttpClient's fault that the OS is unable to reclaim resources of
closed connection. However, what definitely looks wrong is that a 204 response
causes unnecessary termination of otherwise perfectly re-usable connection.
This does look like a bug.
Oleg
> 204 response causes unnecessary termination of re-usable connection
> --------------------------------------------------------------------
>
> 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
> Fix For: 4.2.2
>
> 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]
