Fwd: Connection timeout doesn't behave the same on windows and linux
Hey guys,
It seems that connection timeout parameter doesn't work on Linux Mint 16
(which is
basically Ubuntu). *Code runs perfectly fine on Windows.* Here's my setup :
*Windows 7 Pro x64 - OK*
Oracle Java JDK 1.7.0_51 x64
*Linux Mint 16 (Petra) - PROBLEM*
java version 1.7.0_51
OpenJDK Runtime Environment (IcedTea 2.4.4) (7u51-2.4.4-0ubuntu0.13.10.1)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
...and here's the code (attached as well) :
public static String doGET(URI uri, ResponseHandlerString handler) {
String response = ;
CloseableHttpClient httpclient = null;
try {
httpclient = HttpClients.custom()
.setRetryHandler(customRetryHandler)
.build();
HttpGet httpget = new HttpGet(uri);
RequestConfig requestConfig = RequestConfig.custom()
* .setConnectTimeout(1000)*
.build();
httpget.setConfig(requestConfig);
// hide pass data in URI
String toLog = hidePassInURI(uri);
// Execute HTTP request
logger.info(Executing request + toLog);
response = httpclient.execute(httpget, handler == null ? new
DummyHandler() : handler);
} catch (ConnectException e) {
logger.error();
logger.error(Database is not available!);
logger.error();
} catch (ClientProtocolException e) {
logger.error(,e);
} catch (IOException e) {
logger.error(,e);
} finally {
if (httpclient != null) {
try {
httpclient.close();
} catch (IOException e) {
}
}
}
return response;
}
*Here's the retry handler :*
public boolean retryRequest(IOException exception, int executionCount,
HttpContext context) {
logger.info(Retrying : exe count is +executionCount);
if (executionCount = 10) {
// Do not retry if over max retry count
return false;
}
if (exception instanceof InterruptedIOException) {
* // Timeout - keep retryingreturn true;*
}
if (exception instanceof UnknownHostException) {
// Unknown host
return false;
}
if (exception instanceof ConnectTimeoutException) {
* // Connection refused - keep retryingreturn true;*
}
if (exception instanceof SSLException) {
// SSL handshake exception
return false;
}
HttpClientContext clientContext = HttpClientContext.adapt(context);
HttpRequest request = clientContext.getRequest();
boolean idempotent = !(request instanceof
HttpEntityEnclosingRequest);
if (idempotent) {
// Retry if the request is considered idempotent
return true;
}
return false;
}
*The problem : when I run this code on linux, there's no 1 sec delay
between consecutive attempts. It just*
*goes over 10 attempts and finished within ~200ms. Why?*
*Am I doing something wrong or this is a bug? Please help.*
*P.S. I'm using http client 4.3.2.*
--
Bratislav Stojanovic, M.Sc.
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Fwd: Connection timeout doesn't behave the same on windows and linux
On 3/3/2014 9:00 AM, Bratislav Stojanovic wrote: It seems that connection timeout parameter doesn't work on Linux Mint 16 (which is basically Ubuntu). *Code runs perfectly fine on Windows.*Here's my setup : snip *.setConnectTimeout(1000)* snip *The problem : when I run this code on linux, there's no 1 sec delay between consecutive attempts. It just * *goes over 10 attempts and finished within ~200ms. Why? * *Am I doing something wrong or this is a bug? Please help. * * P.S. I'm using http client 4.3.2.* I assume that the service it's trying to connect to is down or in some way unavailable. What is the exact status? If the server is reachable on that port but the http server is not running, a connection attempt will be instantly refused, there's no reason to wait for the timeout period. In order for a full second to pass, the port must be completely unreachable, which means the server either needs to be down or it needs to be firewalled in a way that offers no response at all rather than a refusal. Is this the case with the server that the Windows version is trying to contact? Thanks, Shawn - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Fwd: Connection timeout doesn't behave the same on windows and linux
Mmmm...good point. I seems to me now this is more architectural problem in my software, not a httpclient issue. What I'm trying to achieve here is basically I need to fire a db query (via REST) during startup of my webapp. DB runs in a separate process and needs around 10 secs to start being responsive. If I fire this query too early, I get connection timeout (on windows). If I fire query at the time when db is just about to finish initialization, my request gets accepted, but db returns 404. If I fire the same query when db finished its initialization procedure, I get of course a proper response. So I figured, I should use retry handler to poke db every second until I get 200, but that's obviously a bad approach, since db can bring up REST interface, but the other parts still haven't completed booting. It's working fine on Windows since it runs on a physical machine, but on Linux it simply skips timeout, since it's a vmware vm (and has limited hw resources). I temporarily solved this by manually adding configurable Thread.sleep timeout so db can pick up. Not sure if there's a better solution. Thanx for your input. P.S. I'm using eXist XML database (exist-db.org) On Mon, Mar 3, 2014 at 7:02 PM, Shawn Heisey s...@elyograg.org wrote: On 3/3/2014 9:00 AM, Bratislav Stojanovic wrote: It seems that connection timeout parameter doesn't work on Linux Mint 16 (which is basically Ubuntu). *Code runs perfectly fine on Windows.*Here's my setup : snip *.setConnectTimeout(1000)* snip *The problem : when I run this code on linux, there's no 1 sec delay between consecutive attempts. It just * *goes over 10 attempts and finished within ~200ms. Why? * *Am I doing something wrong or this is a bug? Please help. * * P.S. I'm using http client 4.3.2.* I assume that the service it's trying to connect to is down or in some way unavailable. What is the exact status? If the server is reachable on that port but the http server is not running, a connection attempt will be instantly refused, there's no reason to wait for the timeout period. In order for a full second to pass, the port must be completely unreachable, which means the server either needs to be down or it needs to be firewalled in a way that offers no response at all rather than a refusal. Is this the case with the server that the Windows version is trying to contact? Thanks, Shawn - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org -- Bratislav Stojanovic, M.Sc.
