Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 98305 invoked from network); 23 Sep 2002 12:04:52 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 23 Sep 2002 12:04:52 -0000 Received: (qmail 10069 invoked by uid 97); 23 Sep 2002 12:05:29 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 10053 invoked by uid 97); 23 Sep 2002 12:05:29 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 10041 invoked by uid 98); 23 Sep 2002 12:05:28 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3D8F03E3.1080801@nose.ch> Date: Mon, 23 Sep 2002 14:06:59 +0200 From: =?ISO-8859-1?Q?Ortwin_Gl=FCck?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: de-ch, en-us MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: [HttpClient] Automatic reconnect in case of closed connection References: <7302FD677189D411813400508B6052F1C373CC@exno02.eu.rsa.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Elwin, Martin wrote: > Ortwin, not sure if I understand why a retry only should be done for 1.1. > Would you mind elaborating on the reasons for that? The current retry logic > is valid for both 1.0 and 1.1, as far as I can tell. Simply because there is no need for a retry in 1.0. Remember 1.0: The server *always* closes the connection. So state of the connection will always be "closed" at the beginning of a request. In 1.1 we have keep-alive connections but which are only kept alive for a certain time. So the connection may be expected open but in fact is closed. Thus a retry is needed after the first attempt. But I am not too happy with your patch. IMHO the problem should be handled by HttpConnetion and not in any higher levels. The problematic call in the code is: connection.isOpen() whose result is unfortunately not related to whether the connection is actually open or closed! So its return value is not well-defined. We'd better fix this HttpConnetion.isOpen() method. Do a read() on the input stream. Unless the connection is open -1 is returned. Unfortunately read() blocks if the connection is open (and no data is available)! Does available() maybe return a meaningful value? This is up to the implementation but should work in theory. (Haven't tried) Martin, could you check this possibility out please? Kind regards Odi -- To unsubscribe, e-mail: For additional commands, e-mail: