You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jess Holle <je...@ptc.com> on 2014/04/07 17:21:38 UTC
Bizarre getParameterMap() failure
We're seeing a bizarre failure of getParameterMap() wherein this servlet
API returns an empty map.
I thought we'd loused this up somehow via our servlet request filters,
but the debugger shows this result on the very first line of our very
first filter -- with the request object being Tomcat's own.
To make matters worse, this is a GET request with a /very /simple URL.
The query string is very simple "?ids=41&jsonSupport=true". The value
of "ids" varies, but it's numeric and the cases I'm looking at are 2 to
4 digits in length. The rest of the request URI is short and all ASCII,
being of the form {webAppName}/xxxx/yy.
This is being reproduced with both 7.0.50 and 7.0.53 -- with mod_jk
1.2.37 and httpd 2.2.26.
As with https://issues.apache.org/bugzilla/show_bug.cgi?id=55695, we are
using Spring MVC -- and getting a similar error message. Given the
point in request handling at which we're getting the erroneous result, I
don't see how this is actually related to Spring MVC, but I also don't
have any idea how one could reproduce the issue without Spring MVC or
our (large proprietary) web application.
Any suggestions for getting to the bottom of this issue would be greatly
appreciated!
--
Jess Holle
Re: Bizarre getParameterMap() failure
Posted by Jess Holle <je...@ptc.com>.
Thanks for the pointers -- I'll make good use of these.
As for #2, yes, the value of getQueryString() is as per expectations.
On 4/7/2014 1:01 PM, Konstantin Kolinko wrote:
> Several quick thoughts....
>
> 1. What is the value of
> request.getAttribute("org.apache.catalina.parameter_parse_failed")
> after you obtain that parameters map?
>
> See Tomcat's o.a.c.filters.FailedRequestFilter for an example.
>
> It will be non-null if there was any trouble when parsing the parameters.
>
>
> 2. What is the value of HttpServletRequest.getQueryString() ?
>
> Is it what you expect?
>
> I think you may also configure AccessLogValve to print it and maybe
> also to print the parameters.
>
> 3. Put a breakpoint into o.a.c.connector.Request#getParameterMap().
> Does it work as expected?
>
> If I understand it correctly, from a quick look the method is not
> thread-safe. There should not be concurrent requests to it.
>
> 4. Try to set ....RECYCLE_FACADES system property to "true"? (See
> sysprops page of configuration reference for the full name of the
> property).
>
> E.g. if request object is shared between threads, there will be problems.
>
> 5.
>>> * Sprint 3.2.2
> There are several known (unrelated) issues,
> http://www.gopivotal.com/security/
>
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Bizarre getParameterMap() failure
Posted by André Warnier <aw...@ice-sa.com>.
Jess Holle wrote:
> FYI, it would appear that this is a case of someone passing a
> ServletRequest object to another thread and invoking methods on it at
> just the wrong point in time so as to utterly corrupt a later request.
> Changing the code to make an appropriate copy of the ServletRequest
> object and pass that instead has resolved our issue.
>
> At a more general level, I certainly understand that the ServletRequest
> interface makes no guarantees about thread safety -- and performance
> reasons for not making the implementation thread-safe. That said, it's
> certainly quite surprising to see this impact later requests due to
> recyling behavior!
>
In any case, thanks for reporting the resolution of the issue, and the way in which it was
resolved.
Some people never do that and it is annoying, because it leaves an inconclusive trace in
the archives, possibly causing someone else in the future to be misled and waste time
chasing dead-ends.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Bizarre getParameterMap() failure
Posted by Jess Holle <je...@ptc.com>.
FYI, it would appear that this is a case of someone passing a
ServletRequest object to another thread and invoking methods on it at
just the wrong point in time so as to utterly corrupt a later request.
Changing the code to make an appropriate copy of the ServletRequest
object and pass that instead has resolved our issue.
At a more general level, I certainly understand that the ServletRequest
interface makes no guarantees about thread safety -- and performance
reasons for not making the implementation thread-safe. That said, it's
certainly quite surprising to see this impact later requests due to
recyling behavior!
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Bizarre getParameterMap() failure
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-04-07 21:28 GMT+04:00 Jess Holle <je...@ptc.com>:
> And looking at the data in Request *before* I invoke getParameter*() in our
> code, I see that parametersParsed is set to "true".
>
> I'm not sure if I should expect this to "true" at this point (entry to my
> first filter) for a GET request with a fairly stock Tomcat 7.0.50/53
> configuration. It doesn't seem like it should be...
>
> Tinkering with the internal state of the Request object, to set
> parametersParsed to false and/or parameterMap to null in the debugger
> doesn't help getParameterMap() succeed, though...
>
> --
> Jess Holle
>
>
> On 4/7/2014 11:52 AM, Jess Holle wrote:
>>
>> P.S. The only way I currently know to reproduce this issue is with a full
>> install of our full commercial product plus optional modules -- and then to
>> load large, sensitive customer data into this product and execute a very
>> specific use case.
>>
>> How this could possibly be related to Spring or /any /specifics of this
>> use is a mystery to me.
>>
>> I understand, however, that the requirements to reproduce this issue throw
>> at least the initial troubleshooting and debugging squarely into my lap,
>> which is why I'm asking for pointers, not filing bugs.
>>
>> A little more version information (in case it is relevant):
>>
>> * Sprint 3.2.2
>> * JDK 7u51
>>
>> --
>> Jess Holle
>>
>> On 4/7/2014 10:21 AM, Jess Holle wrote:
>>>
>>> We're seeing a bizarre failure of getParameterMap() wherein this servlet
>>> API returns an empty map.
>>>
>>> I thought we'd loused this up somehow via our servlet request filters,
>>> but the debugger shows this result on the very first line of our very first
>>> filter -- with the request object being Tomcat's own.
>>>
>>> To make matters worse, this is a GET request with a /very /simple URL.
>>>
>>> The query string is very simple "?ids=41&jsonSupport=true". The value of
>>> "ids" varies, but it's numeric and the cases I'm looking at are 2 to 4
>>> digits in length. The rest of the request URI is short and all ASCII, being
>>> of the form {webAppName}/xxxx/yy.
>>>
>>> This is being reproduced with both 7.0.50 and 7.0.53 -- with mod_jk
>>> 1.2.37 and httpd 2.2.26.
>>>
>>> As with https://issues.apache.org/bugzilla/show_bug.cgi?id=55695, we are
>>> using Spring MVC -- and getting a similar error message. Given the point in
>>> request handling at which we're getting the erroneous result, I don't see
>>> how this is actually related to Spring MVC, but I also don't have any idea
>>> how one could reproduce the issue without Spring MVC or our (large
>>> proprietary) web application.
>>>
>>> Any suggestions for getting to the bottom of this issue would be greatly
>>> appreciated!
>>>
Several quick thoughts....
1. What is the value of
request.getAttribute("org.apache.catalina.parameter_parse_failed")
after you obtain that parameters map?
See Tomcat's o.a.c.filters.FailedRequestFilter for an example.
It will be non-null if there was any trouble when parsing the parameters.
2. What is the value of HttpServletRequest.getQueryString() ?
Is it what you expect?
I think you may also configure AccessLogValve to print it and maybe
also to print the parameters.
3. Put a breakpoint into o.a.c.connector.Request#getParameterMap().
Does it work as expected?
If I understand it correctly, from a quick look the method is not
thread-safe. There should not be concurrent requests to it.
4. Try to set ....RECYCLE_FACADES system property to "true"? (See
sysprops page of configuration reference for the full name of the
property).
E.g. if request object is shared between threads, there will be problems.
5.
>> * Sprint 3.2.2
There are several known (unrelated) issues,
http://www.gopivotal.com/security/
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Bizarre getParameterMap() failure
Posted by Jess Holle <je...@ptc.com>.
And looking at the data in Request *before* I invoke getParameter*() in
our code, I see that parametersParsed is set to "true".
I'm not sure if I should expect this to "true" at this point (entry to
my first filter) for a GET request with a fairly stock Tomcat 7.0.50/53
configuration. It doesn't seem like it should be...
Tinkering with the internal state of the Request object, to set
parametersParsed to false and/or parameterMap to null in the debugger
doesn't help getParameterMap() succeed, though...
--
Jess Holle
On 4/7/2014 11:52 AM, Jess Holle wrote:
> P.S. The only way I currently know to reproduce this issue is with a
> full install of our full commercial product plus optional modules --
> and then to load large, sensitive customer data into this product and
> execute a very specific use case.
>
> How this could possibly be related to Spring or /any /specifics of
> this use is a mystery to me.
>
> I understand, however, that the requirements to reproduce this issue
> throw at least the initial troubleshooting and debugging squarely into
> my lap, which is why I'm asking for pointers, not filing bugs.
>
> A little more version information (in case it is relevant):
>
> * Sprint 3.2.2
> * JDK 7u51
>
> --
> Jess Holle
>
> On 4/7/2014 10:21 AM, Jess Holle wrote:
>> We're seeing a bizarre failure of getParameterMap() wherein this
>> servlet API returns an empty map.
>>
>> I thought we'd loused this up somehow via our servlet request
>> filters, but the debugger shows this result on the very first line of
>> our very first filter -- with the request object being Tomcat's own.
>>
>> To make matters worse, this is a GET request with a /very /simple URL.
>>
>> The query string is very simple "?ids=41&jsonSupport=true". The value
>> of "ids" varies, but it's numeric and the cases I'm looking at are 2
>> to 4 digits in length. The rest of the request URI is short and all
>> ASCII, being of the form {webAppName}/xxxx/yy.
>>
>> This is being reproduced with both 7.0.50 and 7.0.53 -- with mod_jk
>> 1.2.37 and httpd 2.2.26.
>>
>> As with https://issues.apache.org/bugzilla/show_bug.cgi?id=55695, we
>> are using Spring MVC -- and getting a similar error message. Given
>> the point in request handling at which we're getting the erroneous
>> result, I don't see how this is actually related to Spring MVC, but I
>> also don't have any idea how one could reproduce the issue without
>> Spring MVC or our (large proprietary) web application.
>>
>> Any suggestions for getting to the bottom of this issue would be
>> greatly appreciated!
>>
>> --
>> Jess Holle
>>
>
Re: Bizarre getParameterMap() failure
Posted by Jess Holle <je...@ptc.com>.
P.S. The only way I currently know to reproduce this issue is with a
full install of our full commercial product plus optional modules -- and
then to load large, sensitive customer data into this product and
execute a very specific use case.
How this could possibly be related to Spring or /any /specifics of this
use is a mystery to me.
I understand, however, that the requirements to reproduce this issue
throw at least the initial troubleshooting and debugging squarely into
my lap, which is why I'm asking for pointers, not filing bugs.
A little more version information (in case it is relevant):
* Sprint 3.2.2
* JDK 7u51
--
Jess Holle
On 4/7/2014 10:21 AM, Jess Holle wrote:
> We're seeing a bizarre failure of getParameterMap() wherein this
> servlet API returns an empty map.
>
> I thought we'd loused this up somehow via our servlet request filters,
> but the debugger shows this result on the very first line of our very
> first filter -- with the request object being Tomcat's own.
>
> To make matters worse, this is a GET request with a /very /simple URL.
>
> The query string is very simple "?ids=41&jsonSupport=true". The value
> of "ids" varies, but it's numeric and the cases I'm looking at are 2
> to 4 digits in length. The rest of the request URI is short and all
> ASCII, being of the form {webAppName}/xxxx/yy.
>
> This is being reproduced with both 7.0.50 and 7.0.53 -- with mod_jk
> 1.2.37 and httpd 2.2.26.
>
> As with https://issues.apache.org/bugzilla/show_bug.cgi?id=55695, we
> are using Spring MVC -- and getting a similar error message. Given the
> point in request handling at which we're getting the erroneous result,
> I don't see how this is actually related to Spring MVC, but I also
> don't have any idea how one could reproduce the issue without Spring
> MVC or our (large proprietary) web application.
>
> Any suggestions for getting to the bottom of this issue would be
> greatly appreciated!
>
> --
> Jess Holle
>