> HTTP_PARAMS.setParameter( CoreConnectionPNames.SO_TIMEOUT, 200);
200 ms = 0.2 seconds. If youre making calls over the internet, you might want to try a timeout of 15000ms (15 seconds). I sometimes set it to 60000ms b/c the internet can lag at times. I would just set your timeout to 15000ms for testing and see if youre still getting the same problems. hth, -Ryan On Tue, Feb 15, 2011 at 7:33 AM, Maxim Veksler <[email protected]> wrote: > On Tue, Feb 15, 2011 at 2:03 PM, Oleg Kalnichevski <[email protected]> > wrote: > > On Tue, 2011-02-15 at 11:38 +0200, Maxim Veksler wrote: > >> Hello everyone, > >> > >> I'm doing a small stress run from my Workstation to my Laptop. > >> The code is attached below. > >> > >> This code emulates a situation where the connection pool runs out of > >> connections. I'm seeking to catch this situation and act properly. > >> My problem is that after a connection is being aborted it is never > renewed. > >> Which leaves ThreadSafeClientConnManager completely unable to serve new > >> requests. > >> > >> I've traced this by putting a break point on > >> "System.out.println(Thread.currentThread().getName() + ": START " + new > >> Date());" then I've stepped all the 4 threads to > >> "HttpResponse response = httpClient.execute(httpGet, httpContext);" > >> (ensuring that non of them is in the middle of a session). After the > >> exception occurs all threads > >> fail to issue another request, and the ThreadSafeClientConnManager does > not > >> renew it's pool of connections. > >> > >> I'm looking for a situation that the code will be safe maintaining, > meaning > >> the ThreadSafeClientConnManager will be able to renew "failed" > connections, > >> this will allow me to reattempt event resubmission. > >> > >> // p.s. On a side note, I would appreciate a quick code review of the > usage > >> with httpclient in the attached sample as I'm new to the library. > >> > > > > The connect timeout of 200 ms is probably too aggressive. Connection > > lease requests likely time out before the connection manager is able to > > allocate a connection. > > > > Oleg > > > > Thanks for your response. > > The test runs for ~25seconds and only then starts to fail. > Once it fails I eclipse trace it, by going step by step over the code > and the failure reproduces on each attempt. > > Should the ThreadSafeClientConnManager attempt the reconnect or do I > need to do manual recovery, if so - How? > > Also, how can I verify that the failure is because of the aggressive > timeout configuration? I'm aiming at EC2, when due to various load on > the virtual machine it's actually possible that socket connect will > take more then 3 seconds... so I assume that this situation is > possible even with more relaxed connect time constraints. > > > Maxim. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
