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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > > -- Bratislav Stojanovic, M.Sc.
