Hi Oleg,
Thanks for the tip. I changed the connect timeout to 0 and the error
disappeared.
Thanks again to you and all the developers for the good work.
Nick
On Thu, 2004-05-27 at 17:58, Kalnichevski, Oleg wrote:
> Nicholas,
>
> HttpClient 2.0 relies on a fairly ugly trick to be able to simulate connect timeout
> on older JDKs (1.2.x, 1.3.x). HttpClient simply spawns a dedicated thread that
> attempts to instantiate a socket. If the process of socket instantiation takes
> longer than the specified limit, HttpClient simply drops the socket on the floor and
> lets the garbage collection to clean up the mess. By no means this mechanism was
> intended to be reliable and sometimes may lead to all sorts of unpleasant side
> effects (for instance, rendering HttpClient EJB unfriendly). Would it be possible to
> disable the connect timeout and see if that makes any difference? I just wonder if
> the third call would still fail, if you had connect timeout disabled
>
> Mike,
> Any idea why closed connection is considered stale?
>
> <snip>
> protected boolean isStale() {
> boolean isStale = true;
> if (isOpen) {
> // the connection is open, but now we have to see if we can read it
> // assume the connection is not stale.
> isStale = false;
> </snip>
>
> This does not really affect any functional aspects but unfortunately it results lots
> of scary noise in the debug log
>
> Oleg
>
>
> -----Original Message-----
> From: Nicholas Rahn [mailto:[EMAIL PROTECTED]
> Sent: Thu 5/27/2004 15:19
> To: [EMAIL PROTECTED]
> Cc:
> Subject: ConnectionTimeoutException thrown without waiting.
> Hello,
>
> We are using HttpClient 2.0 within a local network to send XML files
> between 2 servers. We send 4 XML documents in 4 separate requests, one
> after the other. The problem we are seeing is that the 3rd request does
> not get sent due to a ConnectionTimeoutException. We have set the
> connection timeout to 5000 milliseconds, but in the logs we see that the
> exception is thrown 2 milliseconds later. After the 3rd request fails,
> the 4th request works fine.
>
> With each request we send the connection:close header so a new
> connection should be opend every time. One strange thing we see is that
> after the 2nd request it takes about 20 seconds for HttpMethodBase to
> acknowledge that the connection should be closed. With the other
> requests, this is almost instantanious.
>
> I am not convinced this is an HttpClient problem as i am unable to
> replicate the problem in my test environment (of course it only happens
> in the production environment :-). Maybe someone has some insight into
> what's happening.
>
> Here are our details:
> HttpClient2-20040526
> j2sdk1.4.2
>
> I've included the wire and debug logs (with the XML documents removed).
> The INFO lines are from our application to give more detail on what the
> exception was.
>
> Thanks for your help,
> Nick
>
>
>
>
>
>
> ______________________________________________________________________
> ---------------------------------------------------------------------
> 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]
