[GitHub] [httpcomponents-client] rhernandez35 opened a new pull request #163: Move javadocs to Builder classes
rhernandez35 opened a new pull request #163: Move javadocs to Builder classes URL: https://github.com/apache/httpcomponents-client/pull/163 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] rhernandez35 opened a new pull request #144: Move javadocs to Builder classes
rhernandez35 opened a new pull request #144: Move javadocs to Builder classes URL: https://github.com/apache/httpcomponents-core/pull/144 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (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:all-tabpanel
]
Chanseok Oh updated HTTPCLIENT-2013:
Description:
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:java}
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)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.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:156)
at
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:374)
at
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
at
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
at com.example.ApacheHttpClient.main(ApacheHttpClient.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
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:368)
at
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
... 10 more
{code}
was:
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
[jira] [Updated] (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:all-tabpanel
]
Chanseok Oh updated HTTPCLIENT-2013:
Description:
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}
was:
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
[jira] [Created] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
Chanseok Oh created HTTPCLIENT-2013:
---
Summary: 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
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}
However, it currently throws the other exception HttpHostConnectException
rather than ConnectTimeoutException.
{code:java}
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)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.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:156)
at
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:374)
at
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
at
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
at com.example.ApacheHttpClient.main(ApacheHttpClient.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
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:368)
at
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
... 10 more
{code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-client] ok2c commented on issue #161: Add RequestConfig builder javadocs
ok2c commented on issue #161: Add RequestConfig builder javadocs URL: https://github.com/apache/httpcomponents-client/pull/161#issuecomment-524017200 @rschmitt I am fine with it as long as the same change get applied consistently to all similar classes in core and client. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-client] rschmitt commented on issue #161: Add RequestConfig builder javadocs
rschmitt commented on issue #161: Add RequestConfig builder javadocs URL: https://github.com/apache/httpcomponents-client/pull/161#issuecomment-524003213 @ok2c Do you agree with his suggestion that the Javadoc should be moved to the builder methods? I like that idea. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-client] bekker commented on a change in pull request #162: Modify RequestConfig Javadoc
bekker commented on a change in pull request #162: Modify RequestConfig Javadoc
URL:
https://github.com/apache/httpcomponents-client/pull/162#discussion_r316756683
##
File path:
httpclient/src/main/java/org/apache/http/client/config/RequestConfig.java
##
@@ -295,11 +293,11 @@ public int getConnectTimeout() {
/**
* Defines the socket timeout ({@code SO_TIMEOUT}) in milliseconds,
- * which is the timeout for waiting for data or, put differently,
+ * which is the timeout for waiting for data or, put differently,
* a maximum period inactivity between two consecutive data packets).
*
* A timeout value of zero is interpreted as an infinite timeout.
- * A negative value is interpreted as undefined (system default).
+ * A negative value is interpreted as undefined.
Review comment:
@garydgregory You're right. I should add more info, not removing it.
But I'm not sure about meaning of 'undefined' here - If it's not system
default, is it 'undefined behavior'? Then there should be a warning about
unexpected results.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-client] bekker commented on a change in pull request #162: Modify RequestConfig Javadoc
bekker commented on a change in pull request #162: Modify RequestConfig Javadoc
URL:
https://github.com/apache/httpcomponents-client/pull/162#discussion_r316756683
##
File path:
httpclient/src/main/java/org/apache/http/client/config/RequestConfig.java
##
@@ -295,11 +293,11 @@ public int getConnectTimeout() {
/**
* Defines the socket timeout ({@code SO_TIMEOUT}) in milliseconds,
- * which is the timeout for waiting for data or, put differently,
+ * which is the timeout for waiting for data or, put differently,
* a maximum period inactivity between two consecutive data packets).
*
* A timeout value of zero is interpreted as an infinite timeout.
- * A negative value is interpreted as undefined (system default).
+ * A negative value is interpreted as undefined.
Review comment:
@garydgregory You're right. I should add more info, not removing it.
But I'm not sure about meaning of 'undefined' here - is it 'undefined
behavior'? Then there should be a warning about unexpected results.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-client] garydgregory commented on a change in pull request #162: Modify RequestConfig Javadoc
garydgregory commented on a change in pull request #162: Modify RequestConfig
Javadoc
URL:
https://github.com/apache/httpcomponents-client/pull/162#discussion_r316748514
##
File path:
httpclient/src/main/java/org/apache/http/client/config/RequestConfig.java
##
@@ -295,11 +293,11 @@ public int getConnectTimeout() {
/**
* Defines the socket timeout ({@code SO_TIMEOUT}) in milliseconds,
- * which is the timeout for waiting for data or, put differently,
+ * which is the timeout for waiting for data or, put differently,
* a maximum period inactivity between two consecutive data packets).
*
* A timeout value of zero is interpreted as an infinite timeout.
- * A negative value is interpreted as undefined (system default).
+ * A negative value is interpreted as undefined.
Review comment:
I think we should keep the docs as is or expand on it, as opposed to
removing information.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1765) SSLConnectionSocketFactory uses connectTimeout for read timeout
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913422#comment-16913422 ] Jang Ryeol commented on HTTPCLIENT-1765: [~ggregory] Sure. I made a small Javadoc change here ([https://github.com/apache/httpcomponents-client/pull/162]) > SSLConnectionSocketFactory uses connectTimeout for read timeout > --- > > Key: HTTPCLIENT-1765 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1765 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5 > Environment: Any >Reporter: SATISH BURNWAL >Priority: Major > Labels: features > > SSLConnectionSocketFactory uses connect timeout value for socket.soTimeout as > well (as per the code in SSLConnectionsocketFactory). Because of this, when > clients are created with such config (below), read timeout is not taking > effect. > RequestConfig.Builder rb = RequestConfig.custom(); > rb.setConnectTimeout(3000); > rb.setExpectContinueEnabled(true); > rb.setSocketTimeout(1); > rb.setAuthenticationEnabled(true); -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-client] bekker commented on a change in pull request #162: Modify RequestConfig Javadoc
bekker commented on a change in pull request #162: Modify RequestConfig Javadoc
URL:
https://github.com/apache/httpcomponents-client/pull/162#discussion_r316742070
##
File path:
httpclient/src/main/java/org/apache/http/client/config/RequestConfig.java
##
@@ -295,11 +293,11 @@ public int getConnectTimeout() {
/**
* Defines the socket timeout ({@code SO_TIMEOUT}) in milliseconds,
- * which is the timeout for waiting for data or, put differently,
+ * which is the timeout for waiting for data or, put differently,
* a maximum period inactivity between two consecutive data packets).
*
* A timeout value of zero is interpreted as an infinite timeout.
- * A negative value is interpreted as undefined (system default).
+ * A negative value is interpreted as undefined.
Review comment:
I was not so sure about other timeouts. Would it be better to make it same
for other timeouts?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-client] ok2c commented on a change in pull request #162: Modify RequestConfig Javadoc
ok2c commented on a change in pull request #162: Modify RequestConfig Javadoc
URL:
https://github.com/apache/httpcomponents-client/pull/162#discussion_r316738153
##
File path:
httpclient/src/main/java/org/apache/http/client/config/RequestConfig.java
##
@@ -295,11 +293,11 @@ public int getConnectTimeout() {
/**
* Defines the socket timeout ({@code SO_TIMEOUT}) in milliseconds,
- * which is the timeout for waiting for data or, put differently,
+ * which is the timeout for waiting for data or, put differently,
* a maximum period inactivity between two consecutive data packets).
*
* A timeout value of zero is interpreted as an infinite timeout.
- * A negative value is interpreted as undefined (system default).
+ * A negative value is interpreted as undefined.
Review comment:
@bekker Thank you for cleaning up the javadocs but why do you want to remove
`(system default)` from socket timeout description and leave it everywhere else?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-client] bekker opened a new pull request #162: Modify RequestConfig Javadoc
bekker opened a new pull request #162: Modify RequestConfig Javadoc URL: https://github.com/apache/httpcomponents-client/pull/162 Cleaned up duplicate sentences and removed 'system default' from getSocketTimeout comment ([HTTPCLIENT-1765](https://issues.apache.org/jira/browse/HTTPCLIENT-1765)). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1765) SSLConnectionSocketFactory uses connectTimeout for read timeout
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913356#comment-16913356 ] Gary Gregory commented on HTTPCLIENT-1765: -- Hi [~northfolk28], Do you think different Javadoc comments would have helped you here? If so, could you propose a PR with improvements? > SSLConnectionSocketFactory uses connectTimeout for read timeout > --- > > Key: HTTPCLIENT-1765 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1765 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5 > Environment: Any >Reporter: SATISH BURNWAL >Priority: Major > Labels: features > > SSLConnectionSocketFactory uses connect timeout value for socket.soTimeout as > well (as per the code in SSLConnectionsocketFactory). Because of this, when > clients are created with such config (below), read timeout is not taking > effect. > RequestConfig.Builder rb = RequestConfig.custom(); > rb.setConnectTimeout(3000); > rb.setExpectContinueEnabled(true); > rb.setSocketTimeout(1); > rb.setAuthenticationEnabled(true); -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1765) SSLConnectionSocketFactory uses connectTimeout for read timeout
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913301#comment-16913301 ] Jang Ryeol commented on HTTPCLIENT-1765: Yeah adding readTimeout is not that hard. I thought it has so unreasonable default that it might be a bug - but it seems no one cares. Anyway thanks for the help. Regards, Jang Ryeol > SSLConnectionSocketFactory uses connectTimeout for read timeout > --- > > Key: HTTPCLIENT-1765 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1765 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5 > Environment: Any >Reporter: SATISH BURNWAL >Priority: Major > Labels: features > > SSLConnectionSocketFactory uses connect timeout value for socket.soTimeout as > well (as per the code in SSLConnectionsocketFactory). Because of this, when > clients are created with such config (below), read timeout is not taking > effect. > RequestConfig.Builder rb = RequestConfig.custom(); > rb.setConnectTimeout(3000); > rb.setExpectContinueEnabled(true); > rb.setSocketTimeout(1); > rb.setAuthenticationEnabled(true); -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Apache HttpAsyncClient throws TimeoutException for successful requests due to failed lease requests
On Thu, 2019-08-22 at 11:18 +0800, 赵博丰 wrote: > Dear all, > > Using the Apache HttpAsyncClient inside Elasticsearch's > RestHighLevelClient, I found a problem that HttpAsyncClient might > throw TimeoutException for successful requests due to failed lease > requests. > > The problem is that AbstractNIOConnPool throws TimeoutException for a > lease request inside release() method, indicating the HttpRequest has > timed out, while it has actually succeeded and has nothing to do with > the following lease request. > > Inside org.apache.http.nio.pool.AbstractNIOConnPool#release method, > after released the connection to the pool, it goes to > processNextPendingRequest(), which then calls processPendingRequest() > for LeaseRequests. > > However, during processing LeaseRequests, it might throw > TimeoutException due to exceeding the connectionRequestTimeout > deadline. The TimeoutException is thrown up through the call stack, > making release() failed and further making the related HttpResponse > failed. Then the affected HttpResponse passes the TimeoutException to > the user while this request/response has actually succeeded. > Hi Zhao, AbstractNIOConnPool#processPendingRequest does not throw any exceptions. The method may fail lease requests that have exceeded their timeout and sticking an instance of TimeoutException into them but nowhere does it throw that exception. So, I am really struggling to understand the issue you are having even after having read this message, SO posting and elasticsearch bug report. To make things worse, together with some other problems, like > improper config params, it might lead to potential memory leak due to > unlimited queued lease requests. > Is there any evidence of that or is that a theory? Oleg > This is my detailed description in SO > https://stackoverflow.com/questions/57552172/apache-httpasyncclient-all-connections-timed-out-suddenly-and-all-future-reque/57584279 > > Also, this problem has been discussed several times in the > Elasticsearch community: > > https://github.com/elastic/elasticsearch/issues/24069 > https://stackoverflow.com/a/48480305/5193455 > https://hibernate.atlassian.net/browse/HSEARCH-2681 > https://discuss.elastic.co/t/elasticsearch-in-docker-and-the-restclient-often-got-java-util-concurrent-timeoutexception/68118 > > The general solution is calling > RequestConfig.Builder.setConnectionRequestTimeout(0). My suggestion > is that perhaps the TimeoutException for lease requests should be > thrown internally to not affect successful HttpResponses. > > Best regards, > Zhao Bofeng - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Apache HttpAsyncClient throws TimeoutException for successful requests due to failed lease requests
Dear all, Using the Apache HttpAsyncClient inside Elasticsearch's RestHighLevelClient, I found a problem that HttpAsyncClient might throw TimeoutException for successful requests due to failed lease requests. The problem is that AbstractNIOConnPool throws TimeoutException for a lease request inside release() method, indicating the HttpRequest has timed out, while it has actually succeeded and has nothing to do with the following lease request. Inside org.apache.http.nio.pool.AbstractNIOConnPool#release method, after released the connection to the pool, it goes to processNextPendingRequest(), which then calls processPendingRequest() for LeaseRequests. However, during processing LeaseRequests, it might throw TimeoutException due to exceeding the connectionRequestTimeout deadline. The TimeoutException is thrown up through the call stack, making release() failed and further making the related HttpResponse failed. Then the affected HttpResponse passes the TimeoutException to the user while this request/response has actually succeeded. To make things worse, together with some other problems, like improper config params, it might lead to potential memory leak due to unlimited queued lease requests. This is my detailed description in SO https://stackoverflow.com/questions/57552172/apache-httpasyncclient-all-connections-timed-out-suddenly-and-all-future-reque/57584279 Also, this problem has been discussed several times in the Elasticsearch community: https://github.com/elastic/elasticsearch/issues/24069 https://stackoverflow.com/a/48480305/5193455 https://hibernate.atlassian.net/browse/HSEARCH-2681 https://discuss.elastic.co/t/elasticsearch-in-docker-and-the-restclient-often-got-java-util-concurrent-timeoutexception/68118 The general solution is calling RequestConfig.Builder.setConnectionRequestTimeout(0). My suggestion is that perhaps the TimeoutException for lease requests should be thrown internally to not affect successful HttpResponses. Best regards, Zhao Bofeng
[jira] [Commented] (HTTPCLIENT-1765) SSLConnectionSocketFactory uses connectTimeout for read timeout
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913158#comment-16913158 ] Oleg Kalnichevski commented on HTTPCLIENT-1765: --- [~northfolk28] Correctly configure timeout settings and you will be fine. Oleg > SSLConnectionSocketFactory uses connectTimeout for read timeout > --- > > Key: HTTPCLIENT-1765 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1765 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5 > Environment: Any >Reporter: SATISH BURNWAL >Priority: Major > Labels: features > > SSLConnectionSocketFactory uses connect timeout value for socket.soTimeout as > well (as per the code in SSLConnectionsocketFactory). Because of this, when > clients are created with such config (below), read timeout is not taking > effect. > RequestConfig.Builder rb = RequestConfig.custom(); > rb.setConnectTimeout(3000); > rb.setExpectContinueEnabled(true); > rb.setSocketTimeout(1); > rb.setAuthenticationEnabled(true); -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1765) SSLConnectionSocketFactory uses connectTimeout for read timeout
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913153#comment-16913153 ] Jang Ryeol commented on HTTPCLIENT-1765: Shouldn't it be system default? As per document (https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/config/RequestConfig.html) it is expected to be system default, not same as connectTimeout. And if you set very small value on connectTimeout, it is likely that socket timeout would occur. Isn't it unreasonable? Regards, Jang Ryeol > SSLConnectionSocketFactory uses connectTimeout for read timeout > --- > > Key: HTTPCLIENT-1765 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1765 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5 > Environment: Any >Reporter: SATISH BURNWAL >Priority: Major > Labels: features > > SSLConnectionSocketFactory uses connect timeout value for socket.soTimeout as > well (as per the code in SSLConnectionsocketFactory). Because of this, when > clients are created with such config (below), read timeout is not taking > effect. > RequestConfig.Builder rb = RequestConfig.custom(); > rb.setConnectTimeout(3000); > rb.setExpectContinueEnabled(true); > rb.setSocketTimeout(1); > rb.setAuthenticationEnabled(true); -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-594) Apache HttpCore 4.4.1 reached EoS
[ https://issues.apache.org/jira/browse/HTTPCORE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913142#comment-16913142 ] Oleg Kalnichevski commented on HTTPCORE-594: [~egonsur] I suppose you want this issue raised with Apache Thrift, not Apache HttpComponents. Oleg > Apache HttpCore 4.4.1 reached EoS > - > > Key: HTTPCORE-594 > URL: https://issues.apache.org/jira/browse/HTTPCORE-594 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore >Affects Versions: 4.4.7 >Reporter: Gonzalo Suardiaz >Priority: Major > Labels: security > > Hello; > We are using *Apache Thrift 0.12.0* in our project, a version using Apache > HttpCore *4.4.1*, which has already reached End of Support (EoS). > When are you planning to include a supported version of Apache HttpCore in > Apache Thrift? > Many thanks in advance! -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1765) SSLConnectionSocketFactory uses connectTimeout for read timeout
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913139#comment-16913139
]
Oleg Kalnichevski commented on HTTPCLIENT-1765:
---
[~northfolk28] In your code you do not set socket timeout anywhere. Neither at
the connection manager nor at the request level. The default socket timeout
value in {{RequestConfig}} is -1 (undefined), not 0 (infinite).
Oleg
> SSLConnectionSocketFactory uses connectTimeout for read timeout
> ---
>
> Key: HTTPCLIENT-1765
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1765
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 4.5
> Environment: Any
>Reporter: SATISH BURNWAL
>Priority: Major
> Labels: features
>
> SSLConnectionSocketFactory uses connect timeout value for socket.soTimeout as
> well (as per the code in SSLConnectionsocketFactory). Because of this, when
> clients are created with such config (below), read timeout is not taking
> effect.
> RequestConfig.Builder rb = RequestConfig.custom();
> rb.setConnectTimeout(3000);
> rb.setExpectContinueEnabled(true);
> rb.setSocketTimeout(1);
> rb.setAuthenticationEnabled(true);
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-client] ok2c commented on issue #161: Add RequestConfig builder javadocs
ok2c commented on issue #161: Add RequestConfig builder javadocs URL: https://github.com/apache/httpcomponents-client/pull/161#issuecomment-523797831 @rhernandez35 Thank you for contributing this PR. It would really cool if you could make similar changes to the config classes in HttpCore. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-client] ok2c merged pull request #161: Add RequestConfig builder javadocs
ok2c merged pull request #161: Add RequestConfig builder javadocs URL: https://github.com/apache/httpcomponents-client/pull/161 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCORE-594) Apache HttpCore 4.4.1 reached EoS
Gonzalo Suardiaz created HTTPCORE-594: - Summary: Apache HttpCore 4.4.1 reached EoS Key: HTTPCORE-594 URL: https://issues.apache.org/jira/browse/HTTPCORE-594 Project: HttpComponents HttpCore Issue Type: Improvement Components: HttpCore Affects Versions: 4.4.7 Reporter: Gonzalo Suardiaz Hello; We are using *Apache Thrift 0.12.0* in our project, a version using Apache HttpCore *4.4.1*, which has already reached End of Support (EoS). When are you planning to include a supported version of Apache HttpCore in Apache Thrift? Many thanks in advance! -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
