[
https://issues.apache.org/jira/browse/HTTPCLIENT-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283673#comment-17283673
]
Linda Werner edited comment on HTTPCLIENT-2136 at 2/12/21, 1:23 PM:
--------------------------------------------------------------------
[~olegk] You are right. Maybe our workaround is not the correct way and my
idea with the default value is wrong, too :) But anyway there is a problem
which only occurs in combination with some network configurations and Apache
HTTPClient. In the tcp dump I see that the connection which is established from
Apache HTTPClient is hold as long as the opposite sends a tcp fin. This also
occurs if the connection is idle. This causes broken connections in some
networks and consumes resources. Maybe I am wrong, but other HTTP client
implementations close idle connections after some time (seconds) of inactivity.
Is there a way to configure a "default connection close after some idle time"
via Apache HTTPClient without implementing a connection pool with idle monitor?
For our requirements a connection pool implementation with idle monitor is a
little bit oversized...
I changed the title of the issue to describe the problem a little bit better...
was (Author: linda.werner):
[~olegk] You are right. Maybe our workaround is not the correct way and my
idea with the default value is wrong, too :) But anyway there is a problem
which only occurs in combination with some network configurations and Apache
HTTPClient. In the tcp dump I see that the connection which is established from
Apache HTTPClient is hold as long as the opposite sends a tcp fin. This also
occurs if the connection is idle. This causes broken connections in some
networks and consumes resources. Maybe I am wrong, but other HTTP client
implementations close idle connections after some time (seconds) of inactivity.
Is there a way to configure a "default connection close after some idle time"
via Apache HTTPClient without implementing a connection pool with idle monitor?
For our requirements a connection pool implementation with idle monitor is a
little bit oversized...
> Idle HTTP connections remain open
> ----------------------------------
>
> Key: HTTPCLIENT-2136
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2136
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
> Affects Versions: 4.5.13
> Reporter: Linda Werner
> Priority: Minor
>
> We found out, that Apache HTTPClient sends HTTP header "Connection:
> keep-alive" by default.
> This behaviour can cause problems on some networks (e.g. Azure network).
> For our implementation we use Spring RestTemplate in combination with Apache
> HTTPClient (to support PATCH http requests). As soon as we used Apache
> HTTPClient we had trouble with some connections, but only on the Azure App
> Service (Azure network) - not locally.
> Our backend app opens connections to other services which are not closed, so
> the tcp connection remains open. The opposition sends tcp FIN after some
> minutes (5 minutes in our case), but the tcp FIN never reaches our app
> service. Something in the Azure network kills the idle tcp connection, but
> the application still holds the damaged tcp connections and tries to send
> data. With no socket read timeout implemented some unspecific time later the
> following exception occurs: "java.net.SocketException: Operation timed out
> (Read failed)". With configured socket read timeout the data read timeout
> exception occurs after the defined time, but this doesn't solve the main
> reason of the broken tcp connection.
> We found some workaround solutions like a connection pool which close idle
> connections after 3 minutes. But in our case we don't want the default
> behaviour to keep all connections open with keep-alive. Our final
> implementation is to set the HTTP header field "Connection: close".
> I think "keep-alive" is not a good default value for the HTTP header field
> "Connection".
> We heard that this issue happens on other networks (AWS), too. It seems to be
> a common practice to close idle connections in networks which use SNAT port
> allocation.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
