Return-Path: Delivered-To: apmail-jakarta-commons-httpclient-dev-archive@www.apache.org Received: (qmail 18593 invoked from network); 13 Feb 2004 15:08:15 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 13 Feb 2004 15:08:15 -0000 Received: (qmail 59088 invoked by uid 500); 13 Feb 2004 15:08:10 -0000 Delivered-To: apmail-jakarta-commons-httpclient-dev-archive@jakarta.apache.org Received: (qmail 59071 invoked by uid 500); 13 Feb 2004 15:08:10 -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 59055 invoked from network); 13 Feb 2004 15:08:09 -0000 Received: from unknown (HELO raven.cmp.com) (192.155.65.102) by daedalus.apache.org with SMTP; 13 Feb 2004 15:08:09 -0000 Received: from gtwsmtp-01.hq.cmp.com (gw59-92.cmp.com [192.155.59.92]) by raven.cmp.com (8.12.8/8.12.8) with ESMTP id i1DF8qNO024680 for ; Fri, 13 Feb 2004 10:08:52 -0500 (EST) Subject: RE: Question on Timeouts To: "Commons HttpClient Project" Cc: "Commons HttpClient Project" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: MCoffey@cmp.com Date: Fri, 13 Feb 2004 10:08:08 -0500 X-MIMETrack: Serialize by Router on gtwsmtp-01/CMPNotes(Release 6.0.2CF2|July 23, 2003) at 02/13/2004 10:08:11 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII 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 Hi ... Apologies for the lack of an introduction. My name is Mike Coffey (if you didn't already catch that part) and I'm currently working at CMP Media on a website project. CMP is a publishing company (we publish DDJ, Information Week, etc. -- a bunch of technology magazines, as well as some in other fields). The project that we're working on is to standardize our website infrastructure (over 100 sites) onto a common Java platform. Me personally -- I've been working with Java for a couple of years (formerly from a software company called ATG), but am now more of a technical project manager. You can quickly see the need for us to do HTTP type content grabs from other feed/content syndication sources. We turned to the project here because why build something that's already done well... I really appreciate your feedback in the e-mail. Interestingly enough, sometimes we see the timeouts work appropriately and sometimes the thread the thread hangs indefinitely....figures it's one of "those" problems...sigh ! 1. We will update to the latest CVS branch, this is something I had in progress anyway given the problems we're seeing. 2. Setting it very low does produce accurate timeouts (at least in development a few months back) -- I will retest. 3. No SSL here....unfortunately, although this issue is probably significantly alleviated in 1.4 or higher, we're on a commercial app server that isn't supporing 1.4 for a few months. 4. See above :) Thank you again, I really appreciate the info., it's an issue that does seem a little odd to me, was hoping that someone had seen something similar. Mike Coffey CMP Media LLC Phone: 781-839-1227 "Kalnichevski, Oleg" gpoint.com> cc: bcc: 02/13/2004 09:22 AM Subject: RE: Question on Timeouts Please respond to "Commons HttpClient Project" Hi there, Timeout settings in your code appear correct. Basically socket reads _should_ timeout, provided the value of transferTimeout is sane. For the lack of better ideas I can only recommend you: (1) upgrade to 2.0rc3 release. Better yet, upgrade to the latest CVS HTTPCLIENT_2_0_BRANCH snapshot (which is quite likely to be the 2.0 final). We've just recently fixed a minor bug with socket timeouts in persistent connections. I do not think you are affected by this bug, but just to be on the safe side (2) Try setting timeout to a ridiculously low value just to see whether read timeouts work at all in your environment. (3) Give JVM 1.4.2 a shot to see if that makes any difference (especially if you are using SSL. Older JSSE implementations seem to have an issue with socket timeouts) (4) Please introduce yourself. I kind of dislike 'hi there' greetings ;-) Oleg -----Original Message----- From: MCoffey@cmp.com [mailto:MCoffey@cmp.com] Sent: Friday, February 13, 2004 15:06 To: Commons HttpClient Project Subject: Re: Question on Timeouts Hello, Thank you for your e-mail...I'm confused a bit, though, as you said: Try specifying an SO_TIMEOUT in milliseconds via HttpClient.setTimeOut() method. But, we're already doing this, no? > client.setTimeout (transferTimeout * 1000); And we're still seeing threads hung indefinitely in socketRead.....now, someone else responded saying that I should also include this: HttpClient().getHostConfiguration().setHost(HOSTNAME, 80,"http" ); where hostname is something like that "www.blabla.com" I'm going to try that, but any other thoughts on why this is hanging indefinitely? Thanks!!!!!! "Jesus M. Salvo Jr." To: Commons HttpClient Project bcc: Subject: Re: Question on Timeouts 02/12/2004 08:20 PM Please respond to "Commons HttpClient Project" MCoffey@cmp.com wrote: > > >Hello, > >I'm using your product for an application that we're building (that fetches some >HTTP content) and I'm running into an issue where it isn't timing out > > < ..snip...> >----------This is how we're connecting ----------------- > > HttpClient client = new HttpClient(); > client.setConnectionTimeout (connectionTimeout * 1000); > client.setTimeout (transferTimeout * 1000); > HttpMethod method = new GetMethod(url); >try { > statusCode = client.executeMethod(method); > } > > > Try specifying an SO_TIMEOUT in milliseconds via HttpClient.setTimeOut() method. Otherwise, it will default to whatever is the default SO_TIMEOUT on your platform. BTW, does anyone have a compilation / list of the defautl SO_TIMEOUT values for each platform ? --------------------------------------------------------------------- To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org