[jira] [Comment Edited] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914970#comment-16914970
]
Chanseok Oh edited comment on HTTPCLIENT-2013 at 8/24/19 2:26 PM:
--
Great. Keep up the good work. Thanks!
was (Author: francium25):
Great. Keep up with the good work.
> Connect timeout throws HttpHostConnectException (ConnectException) instead of
> ConnectTimeoutException (IOException)
> ---
>
> Key: HTTPCLIENT-2013
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.9
> Environment: Linux
> openjdk version "1.8.0_222"
> OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10)
> OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
>Reporter: Chanseok Oh
>Priority: Minor
>
> It is obvious from the code in DefaultHttpClientConnectionOperator that it is
> supposed to throw ConnectTimeoutException in the case of connection timeout:
> {code:java}
> } catch (final ConnectException ex) {
> if (last) {
> final String msg = ex.getMessage();
> throw "Connection timed out".equals(msg)
> ? new ConnectTimeoutException(ex, host, addresses)
> : new HttpHostConnectException(ex, host, addresses);
> }
> {code}
> Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP
> Client), and our production code handling ConnectionException got broken due
> to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that
> extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException
> and not a ConnectionException.)
> Java version:
> {code}
> openjdk version "1.8.0_222"
> OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10)
> OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
> {code}
> Example code to reproduce:
> {code:java}
> public static void main(String[] args) throws IOException {
>// example.com is reserved by the DNS standard and will always trigger
> timeout
>try (CloseableHttpClient client = HttpClients.createDefault();
>CloseableHttpResponse response = client.execute(new
> HttpGet("https://example.com:81;))) {}
> }
> {code}
> It currently throws the other exception HttpHostConnectException rather than
> the supposed ConnectTimeoutException.
> {code}
> Exception in thread "main" org.apache.http.conn.HttpHostConnectException:
> Connect to example.com:81 [example.com/93.184.216.34,
> example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out
> (Connection timed out)
> at
> org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138)
> at
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314)
> at
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357)
> at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218)
> at
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:194)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:85)
> at
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
> at
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
> at com.example.ApacheHttpClient2.main(ApacheHttpClient2.java:13)
> Caused by: java.net.ConnectException: Connection timed out (Connection timed
> out)
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:666)
> at
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:251)
> at
> org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:118)
> ... 10 more
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914500#comment-16914500
]
Chanseok Oh edited comment on HTTPCLIENT-2013 at 8/23/19 5:45 PM:
--
What I am saying is that, you catch {{ConnectException}}, but obviously you
don't always re-throw it as {{HttpHostConnectException}}, according to the
current code. Based on the actual exception message of the caught
{{ConnectException}}, you sometimes (are supposed to) throw
{{ConnectTimeoutException}}, which is not {{ConnectException}}. And this is
triggered only when the exception message is precisely {{Connection timed
out}}, which is obviously for the connection timeout case. I am saying that now
this is not happening here. If you are to say the current behavior to always
throw {{HttpHostConnectException}} is correct, I think it should rather be that
you should really take out the following useless/incorrect/dangerous code to
check the exception message.
{code:java}
throw "Connection timed out".equals(msg) ? ... : ...
{code}
was (Author: francium25):
What I am saying is that, you catch {{ConnectException}}, but obviously you
don't always re-throw it as {{HttpHostConnectException}}, according to the
current code. Based on the actual exception message of the caught
{{ConnectException}}, you sometimes (are supposed to) throw
{{ConnectTimeoutException}}, which is not {{ConnectException}}. And this is
triggered only when the exception message is precisely {{Connection timed
out}}, which is obviously for the connection timeout case. I am saying that now
this is not happening here. If you are to say the current behavior is correct,
I think it should rather be than you should really take out the following
useless/incorrect/dangerous code to check the exception message.
{code:java}
throw "Connection timed out".equals(msg) ? ... : ...
{code}
> Connect timeout throws HttpHostConnectException (ConnectException) instead of
> ConnectTimeoutException (IOException)
> ---
>
> Key: HTTPCLIENT-2013
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 4.5.9
> Environment: Linux
> openjdk version "1.8.0_222"
> OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10)
> OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
>Reporter: Chanseok Oh
>Priority: Major
>
> It is obvious from the code in DefaultHttpClientConnectionOperator that it is
> supposed to throw ConnectTimeoutException in the case of connection timeout:
> {code:java}
> } catch (final ConnectException ex) {
> if (last) {
> final String msg = ex.getMessage();
> throw "Connection timed out".equals(msg)
> ? new ConnectTimeoutException(ex, host, addresses)
> : new HttpHostConnectException(ex, host, addresses);
> }
> {code}
> Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP
> Client), and our production code handling ConnectionException got broken due
> to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that
> extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException
> and not a ConnectionException.)
> Java version:
> {code}
> openjdk version "1.8.0_222"
> OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10)
> OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
> {code}
> Example code to reproduce:
> {code:java}
> public static void main(String[] args) throws IOException {
>// example.com is reserved by the DNS standard and will always trigger
> timeout
>try (CloseableHttpClient client = HttpClients.createDefault();
>CloseableHttpResponse response = client.execute(new
> HttpGet("https://example.com:81;))) {}
> }
> {code}
> It currently throws the other exception HttpHostConnectException rather than
> the supposed ConnectTimeoutException.
> {code}
> Exception in thread "main" org.apache.http.conn.HttpHostConnectException:
> Connect to example.com:81 [example.com/93.184.216.34,
> example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out
> (Connection timed out)
> at
> org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138)
> at
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314)
> at
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357)
> at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218)
> at
>
[jira] [Comment Edited] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914500#comment-16914500
]
Chanseok Oh edited comment on HTTPCLIENT-2013 at 8/23/19 5:44 PM:
--
What I am saying is that, you catch {{ConnectException}}, but obviously you
don't always re-throw it as {{HttpHostConnectException}}, according to the
current code. Based on the actual exception message of the caught
{{ConnectException}}, you sometimes (are supposed to) throw
{{ConnectTimeoutException}}, which is not {{ConnectException}}. And this is
triggered only when the exception message is precisely {{Connection timed
out}}, which is obviously for the connection timeout case. I am saying that now
this is not happening here. If you are to say the current behavior is correct,
I think it should rather be than you should really take out the following
useless/incorrect/dangerous code to check the exception message.
{code:java}
throw "Connection timed out".equals(msg) ? ... : ...
{code}
was (Author: francium25):
What I am saying is that, you catch {{ConnectException}}, but obviously you
don't always re-throw it as {{HttpHostConnectException}}, according to the
current code. Based on the actual exception message of the caught
{{ConnectException}}, you sometimes (are supposed to) throw
{{ConnectTimeoutException}}, which is not {{ConnectException}}. And this is
triggered only when the exception is precisely {{Connection timed out}}, which
is obviously for the connection timeout case. I am saying that now this is not
happening here. If you are to say the current behavior is correct, I think it
should rather be than you should really take out the following
useless/incorrect/dangerous code to check the exception message.
{code:java}
throw "Connection timed out".equals(msg) ? ... : ...
{code}
> Connect timeout throws HttpHostConnectException (ConnectException) instead of
> ConnectTimeoutException (IOException)
> ---
>
> Key: HTTPCLIENT-2013
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 4.5.9
> Environment: Linux
> openjdk version "1.8.0_222"
> OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10)
> OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
>Reporter: Chanseok Oh
>Priority: Major
>
> It is obvious from the code in DefaultHttpClientConnectionOperator that it is
> supposed to throw ConnectTimeoutException in the case of connection timeout:
> {code:java}
> } catch (final ConnectException ex) {
> if (last) {
> final String msg = ex.getMessage();
> throw "Connection timed out".equals(msg)
> ? new ConnectTimeoutException(ex, host, addresses)
> : new HttpHostConnectException(ex, host, addresses);
> }
> {code}
> Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP
> Client), and our production code handling ConnectionException got broken due
> to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that
> extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException
> and not a ConnectionException.)
> Java version:
> {code}
> openjdk version "1.8.0_222"
> OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10)
> OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
> {code}
> Example code to reproduce:
> {code:java}
> public static void main(String[] args) throws IOException {
>// example.com is reserved by the DNS standard and will always trigger
> timeout
>try (CloseableHttpClient client = HttpClients.createDefault();
>CloseableHttpResponse response = client.execute(new
> HttpGet("https://example.com:81;))) {}
> }
> {code}
> It currently throws the other exception HttpHostConnectException rather than
> the supposed ConnectTimeoutException.
> {code}
> Exception in thread "main" org.apache.http.conn.HttpHostConnectException:
> Connect to example.com:81 [example.com/93.184.216.34,
> example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out
> (Connection timed out)
> at
> org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138)
> at
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314)
> at
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357)
> at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218)
> at
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:194)
>
