Both set socket timeout and set connection timeout work for us. You may want to
use the second method below:
public void setConnectionManagerTimeout(long timeout)
Sets the timeout in milliseconds used when retrieving an HTTP connection from
the HTTP connection manager.
public void setConnectionTimeout(int timeout)
Sets the timeout until a connection is etablished. A value of zero means the
timeout is not used. The default value is zero.
i.e.,
client.getHttpConnectionManager().
getParams().setConnectionTimeout(x);
-Fang
-----Original Message-----
From: KARR, DAVID (ATTSI) [mailto:[email protected]]
Sent: Wednesday, July 06, 2011 1:22 PM
To: HttpClient User Discussion
Subject: Old HttpClient (3.0.1) seems to ignore connection timeout, does 4.1.1
do it better?
I'm in the planning stages of converting some code that uses HttpClient 3.0.1
to upgrade to 4.1.1 (or whatever is the latest when I get to that point).
There is one symptom that we're seeing with 3.0.1 that I'm wondering will be
fixed in 4.1.1.
We've always set both a socket timeout and a connection timeout, but I could
never figure out a valid way to test the latter, so I wasn't sure if it was
actually doing anything. I've since gotten more information that may lead to a
valid test case.
One symptom that we see on some of our test servers sometimes is that a
connection is attempted to a host that is blocked by the firewall, and instead
of failing the connection immediately, the connection hangs for a long time and
gets reported as a "stuck thread" in WebLogic after 600 seconds.
We see the following stack trace (excerpt):
java.net.PlainSocketImpl.socketConnect(Native Method)
java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
java.net.Socket.connect(Socket.java:529)
com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:550)
com.sun.net.ssl.internal.ssl.SSLSocketImpl.<init>(SSLSocketImpl.java:394)
com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:123)
org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:81)
org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:126)
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:706)
Our connection timeout is set to 90 seconds (probably hugely more than it needs
to be). Being that it's sitting in "socketConnect()", it looks to me like it's
still trying to connect, but it's obviously not timing out after 90 seconds.
We set the read and connection timeouts like this:
------------------
HttpClientParams clientParams = new HttpClientParams();
clientParams.setSoTimeout(readTimeout);
clientParams.setConnectionManagerTimeout(connectionTimeout);
HttpClient httpClient = new HttpClient(clientParams);
------------------
We're doing this very differently in the code that's using the 4.1.1
implementation. Both values are in milliseconds.
The question is: Is this bad behavior one of the known problems with HttpClient
3.0.1? Should I expect it to better respect the connection timeout with 4.1.1?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
