Tomcat 5.5 Dropping Servlet Parameters

[Rob Heim <ro...@gmail.com>]

Has anyone seen a problem similar to the following:

We use OpenSTA to generate varying degrees of load to test our application
j2ee app using JBoss 4.0.3(Tomcat5.5)/Hibernate/MSSQL.

At low levels (75 users generating approx 5000 requests/minute) the tests
complete without issue. However, when we try and ramp up the test to more
modest levels (150 users generating approx 10,000 requests/minute) our test
fails. Most (over 99%) of all the calls are completed just fine, however on
about 25 random Servlet requests (all POSTS), the parameters are null.

Checking our test we noted that OpenSTA sent each of the incorrect requests
with the correct parameters. Also, using a packet sniffer on the webserver
machine, we verified that the webserver received all the packets containing
these parameters. However the application fails to properly process these
requests since it thinks the parameters weren't submitted. We have debug
code in place which logs a message once a servlet begins processing the
request and can show all the parameters it received. For these cases, no
parameters are there.

After additional testing we have determined that there is a correlation
between the maxThreads parameter and these problems.  By setting the
maxThreads to higher values we can eliminate these errors.  Unfortunately
this is not a viable option.  On our machines, for our 200 VU tests we need
150 threads.  The webserver grinds itself into the ground trying to process
this many concurrent requests.  On our previous release using Weblogic
Server 7.0 (SP5) we only needed 40 threads for the same load.

Here is how the HTTP Connector is currently configured

      <!-- A HTTP/1.1 Connector on port 8080 -->
      <Connector port="8080" address="${ jboss.bind.address}"
         maxThreads="250" strategy="ms" maxHttpHeaderSize="8192"
         emptySessionPath="true"
         enableLookups="false" redirectPort="8443" acceptCount="100"
         connectionTimeout="20000" disableUploadTimeout="true"/>

We tried playing around with the bufferSize parameter as well but that
didn't seem to have any affect on this.

Has anyone else seen this issue?

-- 
-Rob Heim