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]

Reply via email to