[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Golovanov updated HTTPCLIENT-2223:
---------------------------------------
    Description: 
Hi.

I am trying to understand why my TLS connections getting closed after small 
period of time.

1) There are no SSL errors ( debugged via javax.net.debug=all -> same TLS 
version and cipher like in real browser )
2) Connection and socket timeout set to 60s
3) Calls closeExpiredConnections() and closeIdleConnections() are disabled.

I expect that the only reason here is "set socket timeout to 0".
It is ok, that before connection released -> its socket timeout set to 0?
And after connection lease -> its socket timeout correctly set to 60s?

// work done, connection released
http-outgoing-7: set socket timeout to 60000
Connection [id: 7][route: \{tls}->http://proxy->https://target] can be kept 
alive indefinitely
http-outgoing-7: set socket timeout to 0
Connection released: [id: 7][route: 
\{tls}->http://proxy->[https://target|https://target/]][total available: 11; 
{*}route allocated: 1 of 100{*}; total allocated: 17 of 10000]

// 10 seconds later ##
Connection request: [route: \{tls}->proxy->target][total available: 13; route 
allocated: 1 of 100; total allocated: 19 of 10000]
Сonnection leased: [id: 7][route: \{tls}->http://proxy->https://target][total 
available: 12; route allocated: 1 of 100; total allocated: 19 of 10000]
http-outgoing-7: set socket timeout to 60000
// going to work with that route, but ...
Connection released: [id: 7][route: 
\{tls}->[http://proxy|http://proxy/]->https://target][total available: 12; 
{*}route allocated: 0 of 100{*}; total allocated: 18 of 10000]
I/O exception (org.apache.http.NoHttpResponseException) caught when processing 
request to \{tls}->http://proxy->https://target: The target server failed to 
respond

  was:
Hi.

I am trying to understand why my TLS connections getting closed after small 
period of time.

1) There are no SSL errors ( debugged via javax.net.debug=all -> same TLS 
version and cipher like in real browser )
2) Connection and socket timeout set to 60s
3) Calls closeExpiredConnections() and closeIdleConnections() are disabled.

I expect that the only reason here is "set socket timeout to 0".
It is ok, that before connection released -> its socket timeout set to 0?
And after connection lease -> its socket timeout correctly set to 60s?

## work done, connection released ##
http-outgoing-7: set socket timeout to 60000
Connection [id: 7][route: \{tls}->http://proxy->https://target] can be kept 
alive indefinitely
http-outgoing-7: set socket timeout to 0
Connection released: [id: 7][route: 
\{tls}->http://proxy->[https://target|https://target/]][total available: 11; 
{*}route allocated: 1 of 100{*}; total allocated: 17 of 10000]

## 10 seconds later ##
Connection request: [route: \{tls}->proxy->target][total available: 13; route 
allocated: 1 of 100; total allocated: 19 of 10000]
Сonnection leased: [id: 7][route: \{tls}->http://proxy->https://target][total 
available: 12; route allocated: 1 of 100; total allocated: 19 of 10000]
http-outgoing-7: set socket timeout to 60000
... going to work with that route, but ...
Connection released: [id: 7][route: 
\{tls}->[http://proxy|http://proxy/]->https://target][total available: 12; 
{*}route allocated: 0 of 100{*}; total allocated: 18 of 10000]
I/O exception (org.apache.http.NoHttpResponseException) caught when processing 
request to \{tls}->http://proxy->https://target: The target server failed to 
respond


> "set socket timeout to 0" before connection released - it ok or not?
> --------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-2223
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2223
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient (classic)
>    Affects Versions: 4.5.13
>         Environment: Docker
> Ubuntu 20.04.2 LTS
> Java(TM) SE Runtime Environment (build 1.8.0_333-b02)
>            Reporter: Oleg Golovanov
>            Priority: Minor
>
> Hi.
> I am trying to understand why my TLS connections getting closed after small 
> period of time.
> 1) There are no SSL errors ( debugged via javax.net.debug=all -> same TLS 
> version and cipher like in real browser )
> 2) Connection and socket timeout set to 60s
> 3) Calls closeExpiredConnections() and closeIdleConnections() are disabled.
> I expect that the only reason here is "set socket timeout to 0".
> It is ok, that before connection released -> its socket timeout set to 0?
> And after connection lease -> its socket timeout correctly set to 60s?
> // work done, connection released
> http-outgoing-7: set socket timeout to 60000
> Connection [id: 7][route: \{tls}->http://proxy->https://target] can be kept 
> alive indefinitely
> http-outgoing-7: set socket timeout to 0
> Connection released: [id: 7][route: 
> \{tls}->http://proxy->[https://target|https://target/]][total available: 11; 
> {*}route allocated: 1 of 100{*}; total allocated: 17 of 10000]
> // 10 seconds later ##
> Connection request: [route: \{tls}->proxy->target][total available: 13; route 
> allocated: 1 of 100; total allocated: 19 of 10000]
> Сonnection leased: [id: 7][route: \{tls}->http://proxy->https://target][total 
> available: 12; route allocated: 1 of 100; total allocated: 19 of 10000]
> http-outgoing-7: set socket timeout to 60000
> // going to work with that route, but ...
> Connection released: [id: 7][route: 
> \{tls}->[http://proxy|http://proxy/]->https://target][total available: 12; 
> {*}route allocated: 0 of 100{*}; total allocated: 18 of 10000]
> I/O exception (org.apache.http.NoHttpResponseException) caught when 
> processing request to \{tls}->http://proxy->https://target: The target server 
> failed to respond



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to