[
https://issues.apache.org/jira/browse/HTTPCORE-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski updated HTTPCORE-310:
---------------------------------------
Component/s: HttpCore
Summary: (regression) DefaultConnectionReuseStrategy incorrectly flags
connections as non-reusable after 204, 205 or 304 status responses (was: 204
response causes unnecessary termination of re-usable connection )
> (regression) DefaultConnectionReuseStrategy incorrectly flags connections as
> non-reusable after 204, 205 or 304 status responses
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-310
> URL: https://issues.apache.org/jira/browse/HTTPCORE-310
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore
> 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]
