Bug 40860 - Tomcat loses request parameters
Summary: Tomcat loses request parameters
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.5.9
Hardware: PC Windows XP
: P2 critical (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-01 04:29 UTC by Thiago Costa
Modified: 2006-11-11 13:41 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thiago Costa 2006-11-01 04:29:15 UTC
Hi,

I’m having a problem with parameters loses in tomcat. It’s an intermittent
problem. That occurs when I do some ajax’s request and then I do one or more
form submissions. 

I put the tomcat in debug mode and  I observed the class CoyoteAdapter – the
method service(). There exists a request variable (CoyoteRequest type) that has
a protected variable requestParametersParsed that is a flag to parse or not
parse the parameters of a post or get. In the end of the method exists a
‘finally’ clause that force the request variable to do a recycle. The recycle
forces the requestParametersParsed variable to change to false. Then in the next
utilization of the class the parameters will be parsed again. 

The problem that I’ve found is in some situations (as described at the start)
the requestParametersParsed variable is true and the parameters are not parsed. 

The consequence of this is that in my servlet when I ask request.getParameter(…)
and it returns null but in my query string or in my post data has the parameter.
The prove of that is when I ask request.getQueryString() and it returns a not
empty string with my parameter.

Ex:

request.getQueryString() = servlet?param=x
request.getParameter(‘param’) = null


See a pierce of the method service of CoyoteAdapter:
 
    public void service(Request req, Response res)
        throws Exception {

…
        try {

            // Parse and set Catalina and configuration specific
            // request parameters
            if ( postParseRequest(req, request, res, response) ) {
                // Calling the container
                connector.getContainer().invoke(request, response);
            }

…
        } finally {
            // Recycle the wrapper request and response
            request.recycle();
            response.recycle();
        }

    }

At line “if postParseRequest(…” the request. requestParametersParsed must be
false but in some situations it is true!

I cant find the cause of the problem but I found the problem. To resolve my
problem I put a request.recycle(); before the line to force the
requestParametersParsed  variable to false.
I don’t want to have a tomcat modified by me. Its not good. 

See the post
http://mail-archives.apache.org/mod_mbox/tomcat-dev/200601.mbox/%3C43D11EAA.1090905@amazon.com.br%3E
He is having the same problem.

Thanks

Thiago
Comment 1 Remy Maucherat 2006-11-01 05:20:50 UTC
I suppose the logical conclusion would be to look why the flag is false, rather
than resort to hacking. Most likely you are seeing concurrent access to the
request object.
Comment 2 Thiago Costa 2006-11-01 06:42:11 UTC
(In reply to comment #1)
> I suppose the logical conclusion would be to look why the flag is false, rather
> than resort to hacking. Most likely you are seeing concurrent access to the
> request object.

But i´m an user and not a developer. As an user i cant do nothing to resolve the
problem. As i observe, the recycle must set to false! There is a finally clause
that force the recycle! I supose that or the recycle may throw an exception or
an other process is accessing the request object.
Comment 3 Mark Thomas 2006-11-11 13:41:00 UTC
A new request object is generated for each request. Therefore, the only ways I
can for what you report to happen are:
- Multiple threads trying to read the parameters at the same time. This isn't
something any of the internal Tomcat code does.
- An exception during the parameter processing.

I have added additional logging if the parameter processing fails to SVN and
this will be included in 5.5.21 onwards.

If you still see this problem post 5.5.21 and there is no helpful information in
the logs, please re-open and provide a test case so I can investigate further.