Return-Path: Delivered-To: apmail-jakarta-commons-httpclient-dev-archive@www.apache.org Received: (qmail 10359 invoked from network); 10 Oct 2003 07:36:58 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 10 Oct 2003 07:36:58 -0000 Received: (qmail 42999 invoked by uid 500); 10 Oct 2003 07:36:33 -0000 Delivered-To: apmail-jakarta-commons-httpclient-dev-archive@jakarta.apache.org Received: (qmail 42982 invoked by uid 500); 10 Oct 2003 07:36:33 -0000 Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Commons HttpClient Project" Reply-To: "Commons HttpClient Project" Delivered-To: mailing list commons-httpclient-dev@jakarta.apache.org Received: (qmail 42968 invoked from network); 10 Oct 2003 07:36:32 -0000 Received: from unknown (HELO exchange.sun.com) (192.18.33.10) by daedalus.apache.org with SMTP; 10 Oct 2003 07:36:32 -0000 Received: (qmail 14058 invoked by uid 50); 10 Oct 2003 07:39:47 -0000 Date: 10 Oct 2003 07:39:47 -0000 Message-ID: <20031010073947.14057.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: commons-httpclient-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 23703] - Freezes w/ MultiThreadedHttpConnectionManager X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23703 Freezes w/ MultiThreadedHttpConnectionManager ------- Additional Comments From olegk@apache.org 2003-10-10 07:39 ------- Adam, There are two layers of code on top of the HttpClient (both I know very little of), so it is really difficult for me to make any soft of informed guesses about a possible cause of the problem. But what I can see from the logs and the code snippets makes me fairly confident about a few things: * I do not see connection being released in the log. I do not why this happens but this is what I see. * In VFS the connection release is supposed to be triggered by closing the input stream. The consumer of the VFS code must ensure that the input stream is closed under all circumstances (including abnormal circumstances). * Please consider downgrading to HttpClient 2.0. CVS HEAD is currently in a state of flux and should be considered experimental. * I can well imagine that there is a bug in the multi-threaded connection manager code that is triggered by some sort of less usual combination of an HTTP HEAD followed by 301, or probably non-compliant HTTP HEAD (that returns a body) followed by 301. But unless the issue is isolated and is reproduceable with a smaller, more manageable test case, it is really hard to tell Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org