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 isStale method came up, and I've been moving from b1 to b2 without any trouble here, httpclient works like a charm and is clearly fast. Right now I know I can upgrade my httpclient version without any surprise, and I simply love that ! Aurelien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [SURVEY] Commons-URI or not?
As a user of jakarta projects I must say I agree with Chris on this one. No offense, but in the way I see it HttpClient isn't big enough to be splitted and to have one more dependency. I met the same trouble as Chris for commons-logging, helpfully most jakarta projects are willing to update to the latest when you ask, but sometimes it takes time. Aurelien Chris Brown a crit : Please NO !!! We're now finding it very difficult to use a lot of Jakarta projects, because of dependency hell... it's becoming worse than Microsoft's famous DLL hell problem. The more self-contained you can keep an API, the better ; yes, there are issues concerning code re-use, but at present, we're having great difficulty using more than one Jakarta project at a time in our projects. If you only use one Jakarta project at a time, you're generally ok. If you try to use more than one Jakarta project at the same time within your own projects, you have to hope that no such library relies upon any other commons component, because chances are that they won't be expecting the same version of each library (they don't always include the latest version of each basic API, and each main Jakarta API has a different release cycle). Commons-logging is generally included as standard. If each version of an API was always backwards-compatible, maybe that'd work, but that's not always pratical, realistic, or efficient. Or start hacking around with classloaders... and this too becomes a futile exercise when you start deploying things on some versions of Tomcat (for example) that helpfully expose common functionality, using perhaps incompatible versions of APIs (usually from commons) that are obsolete (or more recent than) the versions of these APIs required by some other empirical Jakarta library. Some of the recent commons components, such as commons-sql, have a ridiculous number of dependencies. One other observation about Commons projects (and Jakarta/Apache in general) ; although code re-use seems like a good idea, I'm now seeing several different projects that aim to do more or less the same thing, such as : - ant and maven - torque and commons-sql - oro and regexp - tapestry, turbine, etc. Furthermore, if there's Log4J, why not just use it, instead of the Commons-Logging layer? If a project goes JDK1.4+ -only after, then migrate to java.util.logging ? On a personal note, I'm hoping that commons-net, which used to just work as-is, doesn't start depending on lots of different API versions... I know this is the HttpClient list, and not some general Jakarta list, but I sincerely hope that one of the few remaining Jakarta projects that doesn't depend on many others doesn't go down the same dependency nightmare route as many of the others, so I wanted to illustrate *why* (as a user) I feel this way... - Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problem with post
I think he's using the 2.0a3 release, and not cvs, and there the Expect: 100-continue was buggy... I say that cause I had the exact same log with tomcat 4 and 2.0a3 Kalnichevski, Oleg a écrit : Vikram Now it is clear as day light, that the web server you are posting requests to does not support (or does not correctly implement) 'Expect: 100-continue' handshake. 1) What web server are you using? Does the server support HTTP/1.1? 2) Follow the instructions from my previous post to work the problem around Cheers Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [INPUT NEEDED] RE: problem with post
Yes, but the LOG.trace(enter HttpConnection.responseAvaliable()); which had a typo isn't anymore in cvs (it has been removed from httpconnection here : http://cvs.apache.org/viewcvs/jakarta-commons/httpclient/src/java/org/apach e/commons/httpclient/HttpConnection.java.diff?r1=1.45r2=1.46diff_format=h So even if you told him to upgrade, I really think he didn't, cause in his log, there's hundred of enter HttpConnection.responseAvaliable(). That's why you can't even work on that possible bug he met :) Kalnichevski, Oleg a écrit : Aurelien Upgrade was the VERY first point on the list in my instructions ;-). The 'expect: 100-continue' story is far from being over yet. I am still working on it. I have been running tests with various browsers. Strangely enough, neither IE nor Mozilla appear to be using 'expect: 100-continue' handshake at all. I am REALLY leaning towards disabling the damn thing per default in order to avoid situations like Vikram found himself in Folks, what do you think? Shall we disable 'expect: 100-continue' handshake per default? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTP Post and HTTP/100 (continue)
Sure, I'll try to reproduce it with wire log, as it doesn't happen on every request :(( Oleg Kalnichevski a écrit : Aurelien, Same request. Could you please produce a wire log of the HTTP communication that causes the problem you mentioned? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTP Post and HTTP/100 (continue)
I'm sorry I have trouble enabling wire log within my webapp. I'm using Turbine and in fact it seems HttpClient took the setting from turbine to log it's info. I can't find an easy way to enable wirelog in a specific file... I'm not used to commons logging. Aurelien Pernoud a écrit : Sure, I'll try to reproduce it with wire log, as it doesn't happen on every request :(( Oleg Kalnichevski a écrit : Aurelien, Same request. Could you please produce a wire log of the HTTP communication that causes the problem you mentioned? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTP Post and HTTP/100 (continue)
Here is stuff I got from a Post Method, after removing the log of method : [25 févr. 2003 16:05:31 DEBUG] - User-Agent: Jakarta Commons-HttpClient/2.0alpha2 [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Host: localhost:8080 [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Cookie: $Version=0; JSESSIONID=6ECE869D6914A8D1E9E5B22813CAEC52; $Path=/generatedApp [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Content-Length: 178 [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Expect: 100-continue [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Content-Type: application/x-www-form-urlencoded [\r\n] [25 févr. 2003 16:05:31 DEBUG] - [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Expecting response [25 févr. 2003 16:05:34 DEBUG] - Waiting for response timeout [25 févr. 2003 16:05:34 DEBUG] - Response not available. Send the request body [25 févr. 2003 16:05:34 DEBUG] - Request body sent [25 févr. 2003 16:05:34 DEBUG] - And I think that's were the missing HTTP/ exception came, but I'm not sure BTW, I think you should remove the log enter HttpConnection.responseAvaliable(), cause I have like 50.000 lines of it in my log for only one request... :/ Aurelien Pernoud a écrit : I'm sorry I have trouble enabling wire log within my webapp. I'm using Turbine and in fact it seems HttpClient took the setting from turbine to log it's info. I can't find an easy way to enable wirelog in a specific file... I'm not used to commons logging. Aurelien Pernoud a écrit : Sure, I'll try to reproduce it with wire log, as it doesn't happen on every request :(( Oleg Kalnichevski a écrit : Aurelien, Same request. Could you please produce a wire log of the HTTP communication that causes the problem you mentioned? Oleg - 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]
RE: HTTP Post and HTTP/100 (continue)
I'm using Tomcat 4.1.18, and my log for Turbine is set to debug (not that crazy ;)), but httpclient is either logging everything, either nothing... very weird. I'll have to look further into it sometime. What you say is weird, I have another line where my post went ok : Oleg Kalnichevski a écrit : Aurelien This is the expected behavior with non-compliant HTTP servers. The HTTP server apparently does not respond with 100-continue as expected. HttpClient resumes sending the request body after 3 second timeout. What HTTP server are working with? It appears to have issues with HTTP 1.1 spec compliance. As to excessive noise in the logs, try using debug verbosity instead trace one. Oleg On Tue, 2003-02-25 at 16:18, Aurelien Pernoud wrote: Here is stuff I got from a Post Method, after removing the log of method : [25 févr. 2003 16:05:31 DEBUG] - User-Agent: Jakarta Commons-HttpClient/2.0alpha2 [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Host: localhost:8080 [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Cookie: $Version=0; JSESSIONID=6ECE869D6914A8D1E9E5B22813CAEC52; $Path=/generatedApp [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Content-Length: 178 [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Expect: 100-continue [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Content-Type: application/x-www-form-urlencoded [\r\n] [25 févr. 2003 16:05:31 DEBUG] - [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Expecting response [25 févr. 2003 16:05:34 DEBUG] - Waiting for response timeout [25 févr. 2003 16:05:34 DEBUG] - Response not available. Send the request body [25 févr. 2003 16:05:34 DEBUG] - Request body sent [25 févr. 2003 16:05:34 DEBUG] - And I think that's were the missing HTTP/ exception came, but I'm not sure BTW, I think you should remove the log enter HttpConnection.responseAvaliable(), cause I have like 50.000 lines of it in my log for only one request... :/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTP Post and HTTP/100 (continue)
Sorry the fiest mail went out too soon... I'm using Tomcat 4.1.18, and my log for Turbine is set to debug (not that crazy ;)), but httpclient is either logging everything, either nothing... very weird. I'll have to look further into it sometime. What you say is weird (to me), I have another line where my post went ok : POST /generatedApp/servlet HTTP/1.1 [\r\n] Adding Host request header User-Agent: Jakarta Commons-HttpClient/2.0alpha2 [\r\n] Host: localhost:8080 [\r\n] Content-Length: 65 [\r\n] Expect: 100-continue [\r\n] Content-Type: application/x-www-form-urlencoded [\r\n] [\r\n] Expecting response Response available HTTP/1.1 100 Continue [\r\n] In fact the only difference with the other log is that the other timed out waiting for response... : Expecting response Waiting for response timeout Response not available. Send the request body Request body sent And I don't understand what happens exactly in this case, either in HttpClient nore on tomcat. You say HttpClient resumes sending the request after timeout, but here you see I don't have any after timeout, I have a Is it good ? I'll try disabling the 100 continue cause I think it's the reason of my trouble. Oleg Kalnichevski a écrit : Aurelien This is the expected behavior with non-compliant HTTP servers. The HTTP server apparently does not respond with 100-continue as expected. HttpClient resumes sending the request body after 3 second timeout. What HTTP server are working with? It appears to have issues with HTTP 1.1 spec compliance. As to excessive noise in the logs, try using debug verbosity instead trace one. Oleg On Tue, 2003-02-25 at 16:18, Aurelien Pernoud wrote: Here is stuff I got from a Post Method, after removing the log of method : [25 févr. 2003 16:05:31 DEBUG] - User-Agent: Jakarta Commons-HttpClient/2.0alpha2 [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Host: localhost:8080 [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Cookie: $Version=0; JSESSIONID=6ECE869D6914A8D1E9E5B22813CAEC52; $Path=/generatedApp [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Content-Length: 178 [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Expect: 100-continue [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Content-Type: application/x-www-form-urlencoded [\r\n] [25 févr. 2003 16:05:31 DEBUG] - [\r\n] [25 févr. 2003 16:05:31 DEBUG] - Expecting response [25 févr. 2003 16:05:34 DEBUG] - Waiting for response timeout [25 févr. 2003 16:05:34 DEBUG] - Response not available. Send the request body [25 févr. 2003 16:05:34 DEBUG] - Request body sent [25 févr. 2003 16:05:34 DEBUG] - And I think that's were the missing HTTP/ exception came, but I'm not sure BTW, I think you should remove the log enter HttpConnection.responseAvaliable(), cause I have like 50.000 lines of it in my log for only one request... :/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTP Post and HTTP/100 (continue)
Oleg Kalnichevski a écrit : Aurelien, Something is fishy about your setup. I have developed 100-continue handshake support for HttpClient using Tomcat 4.1.18. It does handle 100-continue correctly. I may need to see the complete log of yours in order to figure out what is going on there. The only theory I can come up with at the moment is that it takes Tomcat more 3 seconds to send 100-continue response out (which would be quite weird). Well I resent my mail including the log cause my first mail (the one you responded) went out too soon, do you need more log ? What is moreover a trouble is that the connection wasn't released after the failed post. Indeed as I call method.releaseConnection() and that response Inputstream is empty, I didn't see anything like HttpConnectionManager.releaseConnection: Release connection for [EMAIL PROTECTED] after that request, whereas every other have it. Should I call myself the releaseconnection(connection used for my request) on connectionmanager, after my request ended or not ? Is it safe ? Are you using Log4j by any chance? If you do, that explains why you keep on getting all TRACE entries in your logs. As Log4J does not support TRACE verbosity, trace events are printed when DEBUG priority is on You've got it, I'm using Log4J... Well I'll see what I can do then. Aurelien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTP Post and HTTP/100 (continue)
Ok I'll try it without the Expect: header tomorrow. But what I can surely say is that I didn't stress Tomcat, I was alone making single requests on it, not even simultaneously. Of course the logging did stress a little, as it logged like 4MB in 30 seconds... I've attached a log more precise on where httpclient went wrong, including trace (thanks to log4j in fact). I have more log of what happened before if you want. I've commented it a little, if you have comments/responses on what I've written please mail me back, as I'm not so familiar with HTTP protocol :) Thanx again for your help, Aurelien Oleg Kalnichevski a écrit : Aurelien, it looks like you have stressed Tomcat to a point that it failed to respond to post requests within 3 sec. Just for a heck of it, try disabling Expect: 100-continue handshake and see if that makes any difference. The problem with connection not being released is troubling. You should file a new bug report for this problem. Cheers Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Bug 13463] - Request/Response race condition when doing multiple requests on the same connection.
Hmm I have a beginning of explanation, though I don't understand why this may cause the test to fail. I was running Tomcat via JBuilder, and using the -classic option (for debug mode). Removing this option, the test goes fine, nothing is logged (no INFO, no WARN). With -classic, it fails. Do you know why ? But I still don't understand why I have some exceptions running my webapps in real separated tomcat... I've checked them, they don't have the -classic option enabled, and I use the httpclient lib the same way I use it in the testcase. I'll check my code again and try to find what's happening there. Aurelien Pernoud a écrit : Well yes when I tried it Friday it failed a lot, I got some responses exchanged (error : I asked for 458 and I got 269 for example)... I'll retest it today, but It sure did fail, or maybe I drank too much, but usually I don't at work... :)) I too tested it in tomcat 4.1.18, weird. [EMAIL PROTECTED] a écrit : 19:24 --- I have tried this new test case, but it seems to work fine for me. I'm running the servet in Tomcat 4.1.18 and have tried it with 1000 concurrent requests. Does this test fail for you? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Bug 13463] - Request/Response race condition when doing multiple requests on the same connection.
Well yes when I tried it Friday it failed a lot, I got some responses exchanged (error : I asked for 458 and I got 269 for example)... I'll retest it today, but It sure did fail, or maybe I drank too much, but usually I don't at work... :)) I too tested it in tomcat 4.1.18, weird. [EMAIL PROTECTED] a écrit : 19:24 --- I have tried this new test case, but it seems to work fine for me. I'm running the servet in Tomcat 4.1.18 and have tried it with 1000 concurrent requests. Does this test fail for you? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Bug 13463] - Request/Response race condition when doing multiple requests on the same connection.
Well, as some changes have been made to httpmethodbase between yesterday evening, and lines changed were about connection, I tried with current CVS, still the same :( I have a little time this afternoon, so I'll try to write a test case, but this test case may need a servlet on the other part (to maintain session). 14:26 --- I've retested my webapp using CVS from yesterday evening, and I still have many exceptions of this type : Error in parsing the status line from the response: unable to find line starting with HTTP/ I compared my new sources to my old ones that were using HttpMultiClient, they're identical in term of using httpclient lib. Except the new one is using HttpMultiThreadConnectionManager instead of HttpMultiClient The old one never throws HttpException, and in the new one, while testing a great number of users using Opensta, if I open a browser myself and try to see what happens, I sometimes have the exception aboved and sometimes streams are being exchanged one another (looks like the original request/race bug where a getresponsebodyasstream is not returning the good stream...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PATCH] Fix for bug 16458
Ok, I'm gonna test it right now and tell you tomorrow morning if everything went ok with my app. Oleg Kalnichevski a écrit : Committed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Bug 13463] - Request/Response race condition when doing multiple requests on the same connection.
Michael Becke a ecrit : Thx to everyone for help, and sorry Mike I made you spend some time on it, I hate it : Not to worry. You've discovered some legitimate bugs in HttpClient's multi-threaded support. Mike I just downloaded and compiled httpclient from current cvs, I'll try your new ConnectionManager to see if it solves my last troubles. Again, thanks for such a reactivity. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Moving to 2.0a2
Michael Becke wrote : Sounds like a reasonable plan. If you haven't already I would recommend looking at HttpClient.executeMethod(). It has a little bit of extra code for handling proxies and for opening the connection. I've seen it, but I think this means I have to use on HttpClient for each user, cause it's using it's private HttpState to execute the request... If there was a HttpClient.executeMethod(HttpState state, HttpConnection conn), that would work, but in my case that's why I first did the hack in the nightly (ex multiclient), to avoid multiple clients (memory / perf...). Am I right ? Also, be sure to release the connections after you use them. You can use either HttpMethod.releaseConnection() or HttpConnection.releaseConnection() to ensure each connection is released. Are you sure I have too ? It seems that in the end HttpMethodBase executeMethod (line 957), there's a call to release the connection used. Thanx for your advice, I'm going into it now. Aurelien Pernoud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Moving to 2.0a2
Michael Becke wrote: You do not need to use HttpClient in particular. I would just suggest you look at it to make sure you've covered all of your bases. Oh ok, I've re-read your first mail, now I understand what you meant. Are you sure I have too ? It seems that in the end HttpMethodBase executeMethod (line 957), there's a call to release the connection used. Yes, you definitely need to release the connection. Thx for your help, I wanted to be sure of what I was doing. BTW, I think I'm going to use the HostConfiguration, it's nice to make a config shareable !! Really nice work guys, the new client seems very logical to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
