Re: SocketException : SSL Implementation not available

Roland Weber wrote: 3. your code does not work with IBM JDK 1.3 in WSAD with Sun JSSE FWIW, we were experimenting with the IBM JDK last year and got lots of mysterious JSSE failures. Finally we realized that we were still using Sun's JSSE implementation. Switching to the IBM JSSE for 1.3 fi

DO NOT REPLY [Bug 19868] - Exception handling in HttpClient requires redesign

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_bu

DO NOT REPLY [Bug 10791] - HTTP Version configuration and tracking

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_bu

DO NOT REPLY [Bug 19868] - Exception handling in HttpClient requires redesign

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_bu

DO NOT REPLY [Bug 19868] - Exception handling in HttpClient requires redesign

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_bu

Re: [RELEASE STOPPER] 2.0rc1 is no-go due to a serious performance issue

Let's try again GZipped. Mike connection.patch.gz Description: GNU Zip compressed data On Wednesday, July 30, 2003, at 12:09 AM, Michael Becke wrote: Here's a first shot at these two items. The attached patch adds some more logging to the MTCM and adds variables to the HttpConnection, Sim

Re: [RELEASE STOPPER] 2.0rc1 is no-go due to a serious performance issue

Here's a first shot at these two items. The attached patch adds some more logging to the MTCM and adds variables to the HttpConnection, SimpleConnectionManager and MTCM for toggling isStale(). Mike On Tuesday, July 29, 2003, at 02:13 PM, Oleg Kalnichevski wrote: All right. I believe the cr

Re: [VOTE] HttpClient 2.0 RC1

+1 A little late from me, but development is proceeding very well. [EMAIL PROTECTED] wrote: +1 -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ "Kalnichevski, Oleg" <[EMAIL PROTECTED]> wrote on 24/07/2003 10:40:30 PM: +1 -Original Message- From:

Re: [RELEASE STOPPER] 2.0rc1 is no-go due to a serious performanceissue

Oleg, I should have time to take care of these two items tonight. I will let you know how far I get. You may have to take over if I don't finish this evening. Mike Oleg Kalnichevski wrote: All right. I believe the crisis can be declared dealt with. Once additional DEBUG log entries for the

Re: [RELEASE STOPPER] 2.0rc1 is no-go due to a serious performanceissue

All right. I believe the crisis can be declared dealt with. Once additional DEBUG log entries for the multi-threaded connection manager are introduced and option to disable 'stale' connection check is added, we will proceed with the 2.0 Release Candidate 1 release. Mike, I see connection pooling a

Re: performance issue

Gosh, i'm sorry you guys wasted your time on what ended up being a platform specific issue. But, I guess this could be good information for someone, somewhere, including me ;-) Todd - Original Message - From: "Michael Becke" <[EMAIL PROTECTED]> To: "Commons HttpClient Project" <[EMAIL P

Re: performance issue

Take a look at Sun BUG ID 4512028. This bug was introduced in 1.4.0 and was fixed in 1.4.1. It appears to effect only Windows. Mike Michael Becke wrote: It does appear to JDK 1.4.0. I just installed 1.4.0_04 on Windows 2000 and beta2 is significantly slower (almost by a factor of 10). Remov

Re: performance issue

It does appear to JDK 1.4.0. I just installed 1.4.0_04 on Windows 2000 and beta2 is significantly slower (almost by a factor of 10). Removing the isStale() check fixes the problem in this case. It seems 1.4.0 does not do well with SO_TIMEOUT. This does not seem to be a problem with Sun 1.3.

RE: performance issue

Todd, There's one benefit of compiling HttpClient locally: you could try ripping the 'stale' connection check and see if it makes any difference. Another guess I can come up with is that this problem may be somehow platform specific. I ran my tests on Redhat 9 with Sun JDK 1.4.2. I'll try to ex

Re: Performance Issue

I just tried my tests against Jetty 4.2.11 with similar results. Jetty does not seem to be the factor here. Todd, could there be anything else effecting the timings? Mike Todd Wolff wrote: Sure, the code is yours to do with as you wish. Related to the performance issue, I am still seeing a d

RE: performance issue

Well ... there must be something different about my environment. The results with JBoss3.2.1-tomcat4.1.24 were much worse! (I decreased threads to 5 and messages per thread to 10 since tomcat defaults max threads per servlet somewhere and I didn't want to dig for the setting.) alpha3 .034 minute

Re: Performance Issue

Todd Wolff wrote: Mike, that certainly makes sense. My intent was to eliminate any wait time for a connection and not to have to pool the connections myself - nor have to deal with any extraneous connections issues, ie. isStale ;-) I hear you. It is certainly okay to do it this way. I just wante

RE: Performance Issue

> As far as disabling isStale(), where do we want to add the preference > for this? Is it per HttpConnectionManager or HttpClient? I'd say per HttpConnectionManager. Disabling 'state' connection check should be considered fine-tuning. Very few folks would really need to do so. There's no point

Re: Performance Issue

> Todd, one thing I noticed is that you are setting maxConnectionsPerHost > to the number of threads you are creating. This pretty much defeats > the purpose of using the MTCM and there is no need to share > connections. There are enough connections for each thread to just own > one. Mike, t

RE: Performance Issue

Todd That's correct. I have been using Tomcat 4.1.24 for my tests. Just for the heck of it, do you mind trying to run your test against Tomcat 4.1.x servlet container? Oleg -Original Message- From: Todd Wolff [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 6:36 PM To: Commons Http

RE: HEAD request hangs

Hi there, The host you are dealing with has HTTP spec compliance problems. The host returns body content in response to HEAD request even though it is not supposed to. Use the following option to enable non-compliant HEAD response body check: HttpClient httpclient = new HttpClient();

Re: Performance Issue

Sure, the code is yours to do with as you wish. Related to the performance issue, I am still seeing a degradation by a factor of roughly 2.5. - and yes, logging is set to error level :-) The problem may be isolated to httpclient's interaction with the Jetty container. Oleg, I recall you saying t

Re: Performance Issue

Kalnichevski, Oleg wrote: All credits should go to Todd. He's done pretty much all the hard work. Agreed. Thank you Todd for bringing this up and for the test code. Maybe it is just me, but I can live with a 1ms penalty that dramatically increases the reliability of the re-used connections. Based

HEAD request hangs

I noticed that invoking a HEAD request to the url http://www.ipswitch.com/cgi/download_eval.pl?product=main results in a hang.. Instead, a GET request returns correctly. I verified that the server supports HEAD requests, and actually it does.. The chunk of code I used is straightforward: String

Re: Performance Issue

Eric Johnson wrote: Ortwin, So far as I know, since Windows 95 it has been possible to measure and wait for time intervals of 1ms. With Windows NT4.0/2000 and later, it is even possible to do microseconds. I think the _really_ coarse timers are a hang-over from Windows 3.1 days, and perhaps s

Re: Performance Issue

Ortwin, So far as I know, since Windows 95 it has been possible to measure and wait for time intervals of 1ms. With Windows NT4.0/2000 and later, it is even possible to do microseconds. I think the _really_ coarse timers are a hang-over from Windows 3.1 days, and perhaps some of the really e

RE: Performance Issue

Eric Johnson a écrit : > > Maybe it is just me, but I can live with a 1ms penalty that > dramatically increases the reliability of the re-used connections. > Based on your research, I think we should keep the isStale() check. > What do others think? Totally agree, I was getting mad before the isS

RE: Performance Issue

Eric, All credits should go to Todd. He's done pretty much all the hard work. > Maybe it is just me, but I can live with a 1ms penalty that dramatically > increases the reliability of the re-used connections. Based on your > research, I think we should keep the isStale() check. What do others

Re: ssl question

Quent, You might also read Bruce Schneier's book called "Applied Cryptography", (and his other books, too). Every security system has its inescapable flaws. HTTPS/SSL/TLS, for example, depends on the certificates not being compromised while they're still valid, and on the computational compl

Re: Performance Issue

Eric Johnson wrote: since isStale() calls setSoTimeout(1), since it cannot set it to zero. Is this platform safe actually? Windows has only very corse timers, will it still be around 1ms or will it be 20-30ms? Maybe it is just me, but I can live with a 1ms penalty that dramatically increases t

Re: Performance Issue

Oleg, Thanks for doing the research! If my math is correct, this means: 2.0b2 - average of 10.23ms per request 2.0rc1 without isStale - average of 8.16ms per request This would seem to correlate exactly with the code - we know that the penalty of calling isStale() should be approximately one mil

Re: ssl question

Querent wrote: Dear Odi, I am using jsse for the ssl implementation. I still want to use HttpClient in my program. As mentioned before, HttpClient uses Sockets as created by JSSE. There is nothing you can configure in HttpClient except of a custom SocketFactory (which you can use to change prope

Re: ssl question

Dear Odi, I am using jsse for the ssl implementation. I still want to use HttpClient in my program. If I am assuming that the server and client certificate both valid and they're communicating to each other. Are they communicating in a secure line? (ie: no one can get or decrypt the data ?) D

Re: Avoid building against Head of Commons Httpclient

Thanks, I have added this line. Hopefully it will work now. > Ingo, > > this will not work. You will need to add a > > > > or something similar. Gump only uses the system classpath, so any classpath > additions defined in the Ant file are ignored. > > It would be nice if there was a sepa

RE: Performance Issue

OK. I did a stupid thing that flawed all my measurements. I have basically ended up measuring the speed of console output ;-). Dumb Russian I am. Todd, are you sure you have not fallen into the same trap? BETA2 is simply more verbose than ALPHA3 ;-) There are the revised numbers (with wire log

Re: Avoid building against Head of Commons Httpclient

Ingo, this will not work. You will need to add a or something similar. Gump only uses the system classpath, so any classpath additions defined in the Ant file are ignored. It would be nice if there was a separate project for the 2.0 branch of Commons-HttpClient, given that the community ha

RE: Performance Issue

Mike, I have run the test with 3 different HttpClient versions and the results I have got are troubling 2.0a3: 50 requests in 0.390 min 2.0b2: 50 requests in 0.423 min 2.0rc1 (with 'stale' connection

Re: Avoid building against Head of Commons Httpclient

> Newbie question: > > What do you mean by CVS HEAD of Commons-HttpClient? > The nightly builds were compiled against the latest version of Commons Httpclient found in CVS. Because there are some incompatible API changes and Slide client is expected to be used with a 2.0 version of Httpclient I

Re: Avoid building against Head of Commons Httpclient

Daniel, The HttpClient code consists of the 2.0 branch and the 2.1/3.0 current development "trunk" = CVS HEAD. Please refer to other resources on the Net about code management, CVS, tagging and branching. Odi Daniel Joshua wrote: Newbie question: What do you mean by CVS HEAD of Commons-HttpC

RE: Avoid building against Head of Commons Httpclient

Newbie question: What do you mean by CVS HEAD of Commons-HttpClient? PS: I have never used CVS or nightly builds before... Regards, Daniel -Original Message- From: Ingo Brunberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, 29 July, 2003 4:58 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]

Avoid building against Head of Commons Httpclient

Hi, I have modified Gump's project definition for Slide, so that it (hopefully) builds against the included commons-httpclient.jar. This should give us working nightly builds again. Regards, Ingo - To unsubscribe, e-mail: [EMAI