tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Apache tomcat concurrency issue
Date Fri, 04 Nov 2016 22:26:27 GMT
Hash: SHA256

Miguel Angel,

On 11/3/16 12:52 PM, Roldan, Miguel Angel [Global Data & Content] wrote:

(Moving this up to the top:)

> Httpd apache server on the front-end v. 2.2 connected to apache 
> tomcat using AJP connector 1.3
> Apache tomcat 7.0.56


> We are facing some random concurrency issues in our tomcat
> environments.
> 1.      We have a web application deployed on Tomcat that handles
> requests from browsers (AJAX and non-AJAX) and also from an
> applet.
> 2.      The requests send by the browser and always gets and posts
> (with application/x-www-form-urlencoded format)
> 3.      The requests made by the applet are compressed and send in
> binary, they are handled by a different Servlet that reads the
> content by executing request.getInputStream().

Are you compressing and sending a big blob called "data" or something
similar? Or are you sending multiple parameters separately compressed?

> 4.      Randomly, mainly after opening the applet from the current
> session or in another session executed on the same server (which
> send some requests in parallel) requests send from the browser
> arrives to the server with an empty request.getParameterMap()

If you are calling request.getInputStream, then you will never get
anything in the parameter map. If your code consumes the request body
in a POST, then Tomcat cannot parse it again.

> 5.      We have reviewed that the request was well formed when it
> leaves the browser and also we are able to monitor it with TCP Dump
> and see that arrives correctly to tomcat.


> 6.      We have introduced a filter on the first position of the
> filter chain: org.apache.catalina.filters.RequestDumperFilter and
> we have validated that at this point we have already lost all of
> the parameters

Good thinking. Are you SURE it's the first filter in the chain? We
aware that the RequestDumperValve will rob the data from your applicatio

> 7.      If we try to execute the request.getInputStream() for this
> problematic requests what we see is that the byte array that
> returns belongs to another request made before to the server.

Obviously, that shouldn't happen.

> 8.      If we re-submit the same request after, it works fine. They
> don't have any kind of special character or exceed a certain
> length.
> 9.      Environment configuration:
> O.S. - Oracle linux
> 10.   Sometimes we are able to reproduce the issue on a
> eclipse-tomcat environment using http connector and we have
> validated that the flag used by the class
> org.apache.catalina.connector.Request parametersParsed is set to
> true.
> Do you have any kind of suggestions on how to further investigate
> the issue?

Are you able to re-test with an updated version of Tomcat 7? Current
version is 7.0.72. Your version is ~2 years old.

Can you post your <Connector> configuration?

Thoughts about what might be happening:

1. Application concurrency/request-object retention bug
2. maxPostSize value too low -- Tomcat is rejecting the request in a
way unexpected by the application
3. Edge case/bug in Tomcat that has been fixed in a more-recent version?

- -chris
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message