Return-Path: X-Original-To: apmail-hc-httpclient-users-archive@www.apache.org Delivered-To: apmail-hc-httpclient-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 027D610AFA for ; Mon, 3 Mar 2014 18:37:12 +0000 (UTC) Received: (qmail 29781 invoked by uid 500); 3 Mar 2014 18:37:11 -0000 Delivered-To: apmail-hc-httpclient-users-archive@hc.apache.org Received: (qmail 29751 invoked by uid 500); 3 Mar 2014 18:37:11 -0000 Mailing-List: contact httpclient-users-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpClient User Discussion" Delivered-To: mailing list httpclient-users@hc.apache.org Received: (qmail 29743 invoked by uid 99); 3 Mar 2014 18:37:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Mar 2014 18:37:11 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of bratislav1983@gmail.com designates 209.85.213.174 as permitted sender) Received: from [209.85.213.174] (HELO mail-ig0-f174.google.com) (209.85.213.174) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Mar 2014 18:37:05 +0000 Received: by mail-ig0-f174.google.com with SMTP id h18so8361557igc.1 for ; Mon, 03 Mar 2014 10:36:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SFfgTXpN+GRtQGq94g1ePrHBKsV16RdrBXc7ixBsy7k=; b=tMv7la8KqLJ3YBMCjcTYToffizImsquLrD9wdmkm1WC/ZSeR4mriUg52wfXKYhfHQp 1yelX+oN/LTTWl7fp42T4EM4hCxmqqBXsQogCUWVn1EfS//1qKEBIdGB5CmWrCDL+rOp tdYI4e9+tRm8SYF22vq0H5IDQqLQ3/EY+UW4rFfGI7UiTP/chwO8oBFZ4yi/C5q7xzwa t2FgV+916qH9z+sBmpyAyBSMzEJr7Bu/5gdURxMf5poZ3K3ZYgdo3GzzbbqQvXPy0J59 B4uQ3Eijsb61C14WvcXPmzb+sPp1ZtEiKtuS2LXX+0MQ/blja90Kkr3/PMa2r3UBtEbP bkfw== MIME-Version: 1.0 X-Received: by 10.50.119.132 with SMTP id ku4mr6566216igb.35.1393871804659; Mon, 03 Mar 2014 10:36:44 -0800 (PST) Received: by 10.64.13.199 with HTTP; Mon, 3 Mar 2014 10:36:44 -0800 (PST) In-Reply-To: <5314C3AF.3070408@elyograg.org> References: <5314C3AF.3070408@elyograg.org> Date: Mon, 3 Mar 2014 19:36:44 +0100 Message-ID: Subject: Re: Fwd: Connection timeout doesn't behave the same on windows and linux From: Bratislav Stojanovic To: HttpClient User Discussion Content-Type: multipart/alternative; boundary=001a1134428ec7800d04f3b811bb X-Virus-Checked: Checked by ClamAV on apache.org --001a1134428ec7800d04f3b811bb Content-Type: text/plain; charset=ISO-8859-1 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 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 : >> > > > > *.setConnectTimeout(1000)* >> > > > > *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-unsubscribe@hc.apache.org > For additional commands, e-mail: httpclient-users-help@hc.apache.org > > -- Bratislav Stojanovic, M.Sc. --001a1134428ec7800d04f3b811bb--