Mike, I wish I could be of more help but I personally have never come across with such a (mis)behavior, nor do I remember anyone reporting it on this mailing list.
> 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. Are you using Websphere Appserver 4.0.x or 5.0.x by any chance? If yes, please make sure you have the latest fixpack applied (4.0.6 and 5.0.2.2 respectively). There have been numerous reports of several java.net.Socket related bugs in IBM JDK 1.3.x implementations. If not, getting all your software up to the latest service is still your best bet. Cheers, Oleg -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, February 13, 2004 16:08 To: Commons HttpClient Project Cc: Commons HttpClient Project Subject: RE: Question on Timeouts 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" <[EMAIL PROTECTED] To: "Commons HttpClient Project" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: <quote> Try specifying an SO_TIMEOUT in milliseconds via HttpClient.setTimeOut() method. </quote> 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: <quote> HttpClient().getHostConfiguration().setHost(HOSTNAME, 80,"http" ); where hostname is something like that "www.blabla.com" </quote> 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 <[EMAIL PROTECTED]> <[EMAIL PROTECTED] cc: asia.com> bcc: Subject: Re: Question on Timeouts 02/12/2004 08:20 PM Please respond to "Commons HttpClient Project" [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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]
