Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@www.apache.org Received: (qmail 47335 invoked from network); 4 Oct 2004 16:43:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 4 Oct 2004 16:43:43 -0000 Received: (qmail 12419 invoked by uid 500); 4 Oct 2004 16:41:59 -0000 Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 12258 invoked by uid 500); 4 Oct 2004 16:41:57 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 12097 invoked by uid 99); 4 Oct 2004 16:41:52 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [192.18.33.10] (HELO exchange.sun.com) (192.18.33.10) by apache.org (qpsmtpd/0.28) with SMTP; Mon, 04 Oct 2004 09:41:50 -0700 Received: (qmail 6749 invoked by uid 50); 4 Oct 2004 16:43:40 -0000 Date: 4 Oct 2004 16:43:40 -0000 Message-ID: <20041004164340.6748.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: tomcat-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 31523] - Request parameters are not always passed to HttpServlet.service X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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://issues.apache.org/bugzilla/show_bug.cgi?id=31523 Request parameters are not always passed to HttpServlet.service ------- Additional Comments From remm@apache.org 2004-10-04 16:43 ------- If your second thread is probably synced, then it's supposed to work. It's still not allowed in the servlet specification (it mandates one thread, which is harsh, but has the big advantage of avoiding trouble). Printing out stuff to the console is quite expensive, so I can definitely understand why it changes things if there's a thread safety issue (which is usually caused by much shorter problematic intervals). The example Peter attached should allow simulating thousands of POST requests, hopefully with multiple parallel requests. I didn't try it yet, because I am busy with other bugfixing for 5.5. --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org