Return-Path: Delivered-To: apmail-hc-dev-archive@www.apache.org Received: (qmail 18202 invoked from network); 28 Jan 2011 02:47:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 28 Jan 2011 02:47:06 -0000 Received: (qmail 21153 invoked by uid 500); 28 Jan 2011 02:47:05 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 21081 invoked by uid 500); 28 Jan 2011 02:47:04 -0000 Mailing-List: contact dev-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list dev@hc.apache.org Received: (qmail 21073 invoked by uid 99); 28 Jan 2011 02:47:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Jan 2011 02:47:04 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Jan 2011 02:47:03 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id p0S2khxH010301 for ; Fri, 28 Jan 2011 02:46:43 GMT Message-ID: <10468147.255651296182803348.JavaMail.jira@thor> Date: Thu, 27 Jan 2011 21:46:43 -0500 (EST) From: "Kennard Consulting (JIRA)" To: dev@hc.apache.org Subject: [jira] Issue Comment Edited: (HTTPCLIENT-1048) PostMethod very slow 'out of the box' for /j_security_check In-Reply-To: <17815809.230401296094244313.JavaMail.jira@thor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HTTPCLIENT-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987898#action_12987898 ] Kennard Consulting edited comment on HTTPCLIENT-1048 at 1/27/11 9:45 PM: ------------------------------------------------------------------------- Oleg, Thanks for your response. I'm afraid the wire log isn't very helpful: it shows the presence/absence of the Expect header, and shows the body being 'pulled' either during/before the request processing - pretty much what you'd expect. But the actual cause of the 2 second slowdown is not revealed. If you try the attached WAR you may be able to discover what is taking 2 seconds? Anyway, if 'expect-continue' is disabled by default in 4.1, that works for me! Thanks, Richard. was (Author: kennardconsulting): Oleg, Thanks for your response. I'm afraid the wire log isn't very helpful: it shows the presence/absence of the Expect header, and shows the body being 'pulled' either during/before the request processing - pretty much what you'd expect. But the actual cause of the 2 second slowdown is not revealed. If you try the attached WAR you may be able to discover what is taking 2 seconds. Anyway, if 'expect-continue' is disabled by default in 4.1, that works for me! Thanks, Richard. > PostMethod very slow 'out of the box' for /j_security_check > ----------------------------------------------------------- > > Key: HTTPCLIENT-1048 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1048 > Project: HttpComponents HttpClient > Issue Type: Bug > Affects Versions: 4.0.3 > Environment: Java 6, Tomcat 6, JBoss 5.1 > Reporter: Kennard Consulting > Attachments: ExpectTest.war > > > First, thanks for an awesome piece of work in HttpClient. I use it every day and it is very useful to me. > HttpClient's default settings include adding an... > Expect: 100-continue > ...header to every PostMethod. This seems to interact poorly with Tomcat's (and possibly other Java EE containers) FormAuthenticator. I tested on both Tomcat 6 and JBoss 5.1.0 (which I believe uses a fork of Tomcat). Testing both with/without the 'Expect' header I see '/j_security_check' login times of: > With Expect header: 2012ms > Without Expect header: 8ms > So the default is some 250x slower. This is without a database or any other complicating factors. It can make a dramatic difference if you are using HttpClient to simulate logging in and retrieving information. > I include a test WAR. To deploy it: > 1. Copy into /webapps > 2. Edit conf/tomcat-users.xml to enable the tomcat/tomcat username/password > 3. Run Tomcat > 4. Hit http://localhost:8080/ExpectTest > 5. Log in as tomcat/tomcat > 6. Hit 'Start Test' > The issue can be worked around by removing the RequestExpectContinue interceptor, but it takes a lot of digging through code to realise this. Otherwise you may simply conclude 'HttpClient is slow'. > According to the HTTP spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3), the 100 header "allows a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body". So perhaps this setting should only apply for 'large' POST bodies, not for simple 'j_username=Foo&j_password=Bar' bodies? > Regards, > Richard -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org