Quantcast

Tomcat 7 - No modifications are allowed to a locked ParameterMap

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Tomcat 7 - No modifications are allowed to a locked ParameterMap

David Wall
We are running Tomcat 7.0.26 and have not see this except before running
high load testing.  It's an odd exception in that our getParam() code is
just calling: String[] pv = request.getParameterValues(name);

That is, we are not making a call that should be attempting to change
any parameter value/map.  We are just trying to retrieve a parameter
value using the standard HttpServletRequest given to JSP/servlet code.

May 2, 2012 1:55:03 AM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.IllegalStateException: No modifications are allowed to a
locked ParameterMap
         at org.apache.catalina.util.ParameterMap.put(ParameterMap.java:170)
         at
org.apache.catalina.connector.Request.getParameterMap(Request.java:1167)
         at
org.apache.catalina.connector.RequestFacade.getParameterMap(RequestFacade.java:444)
         at
org.apache.catalina.core.ApplicationHttpRequest.parseParameters(ApplicationHttpRequest.java:755)
         at
org.apache.catalina.core.ApplicationHttpRequest.getParameterValues(ApplicationHttpRequest.java:416)
         at com.esignforms.html.ServletUtil.getParam(ServletUtil.java:128)
         at com.esignforms.jsp.PageBean.getParam(PageBean.java:2813)
         at
com.esignforms.jsp.PageBean.getViewOnlyPickupCodeFromRequest(PageBean.java:4131)
         at com.esignforms.jsp.PageBean.init(PageBean.java:277)
         at
org.apache.jsp.playerRegistration2_jsp._jspService(playerRegistration2_jsp.java:92)
         at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
         at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
         at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
         at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
         at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
         at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
         at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
         at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:471)
         at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:402)
         at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:329)
         at com.esignforms.servlet.Launch.doGet(Launch.java:100)
         at com.esignforms.servlet.Launch.doPost(Launch.java:116)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
         at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
         at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
         at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
         at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
         at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581)
         at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
         at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
         at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
         at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
         at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
         at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
         at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
         at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1600)
         at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
         at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
         at java.lang.Thread.run(Thread.java:662)

It is coming from our Launch servlet at the line where we essentially
are forwarding the request to a JSP page using:
request.getRequestDispatcher(url).forward(request, response);

Why would Tomcat be changing the map when I'm just requesting to get a
value from it?

Thanks,
David


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Tomcat 7 - No modifications are allowed to a locked ParameterMap

Caldarale, Charles R
> From: David Wall [mailto:[hidden email]]
> Subject: Tomcat 7 - No modifications are allowed to a locked ParameterMap

> May 2, 2012 1:55:03 AM org.apache.catalina.core.ApplicationDispatcher invoke
> SEVERE: Servlet.service() for servlet jsp threw exception
> java.lang.IllegalStateException: No modifications are allowed to a
> locked ParameterMap

Both this symptom and your earlier one about creating a session after a response has been committed are representative of the kinds of errors seen when a webapp stores references in an inappropriate scope.  For example, keeping a reference to a request or response object in a static field, a session, or a thread-local, will often result in the wrong object being used later on.  This is especially evident under high-load situations...

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

David Wall


On 5/2/2012 2:17 PM, Caldarale, Charles R wrote:
> Both this symptom and your earlier one about creating a session after a response has been committed are representative of the kinds of errors seen when a webapp stores references in an inappropriate scope.  For example, keeping a reference to a request or response object in a static field, a session, or a thread-local, will often result in the wrong object being used later on.  This is especially evident under high-load situations...
>
>   - Chuck

Thanks, Chuck.  I know you are an expert here.  That could be since it's
very odd to have all of these different sorts of exceptions occurring on
what should be standard JSP/servlet code, as if my
request/response/session objects are messed up.

That being said, our "PageBean" class associated with our JSPs are all
at the 'request' scope:

<jsp:useBean id="bean" scope="request"
class="org.example.PlayerRegistration2Page" />

The PageBean holds a reference to the request, response and session
objects, as defined in the JSP's java code, but we are passing in the
standard objects our page should be getting from Tomcat:

bean.init(session,request,response);

I am pretty sure we never store the request/response objects in the
session, static field or thread-local.  So once a response is sent back,
it seems that our PageBean class should fall out of scope as it was tied
into the request scope.

We have implemented our own HttpSessionListener so we can track
sessionCreated and sessionDestroyed events.  So I am saving the session
objects between the two events which we use to show "all active users"
including the session start time and last accessed time (which is why we
store the actual session object).   We started 13,350 sessions during
the test, with a max of 1800 concurrent sessions.  But we don't seem to
have trouble keeping track of them because now that the testing is done,
we can see just the current user sessions listed (in this case, just
two, both started recently), so all of those sessions eventually ended
or expired and were then removed from our tracking list.

Is it possible that if we keep a handle on the session (though we remove
that on sessionDestroyed) this prevents Tomcat from some sort of GC
issue with respect to the sessions?

Your thoughts on this are much appreciated.

David


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Tomcat 7 - No modifications are allowed to a locked ParameterMap

Caldarale, Charles R
> From: David Wall [mailto:[hidden email]]
> Subject: Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

> I am pretty sure we never store the request/response objects in the
> session, static field or thread-local.

> What about in your servlets?  Or third-party libraries?

> Is it possible that if we keep a handle on the session (though we
> remove that on sessionDestroyed) this prevents Tomcat from some
> sort of GC issue with respect to the sessions?

No, it will just increase your heap usage.  Tomcat doesn't do GC - that's a function of the JVM.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

David Wall
In reply to this post by Caldarale, Charles R


On 5/2/2012 2:17 PM, Caldarale, Charles R wrote:
> Both this symptom and your earlier one about creating a session after a response has been committed are representative of the kinds of errors seen when a webapp stores references in an inappropriate scope.  For example, keeping a reference to a request or response object in a static field, a session, or a thread-local, will often result in the wrong object being used later on.  This is especially evident under high-load situations...
>
>   - Chuck

Okay, it looks like you put me on the right track. Just discovered that
one of the servlets uses an instance variable to hold the
request/response/session objects. Oy, and it was like that since 2008!  
Not positive this will resolve all the issues, but it's a clear bug.  
Thanks for your tip.

David

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David,

On 5/2/12 8:01 PM, David Wall wrote:

>
>
> On 5/2/2012 2:17 PM, Caldarale, Charles R wrote:
>> Both this symptom and your earlier one about creating a session
>> after a response has been committed are representative of the
>> kinds of errors seen when a webapp stores references in an
>> inappropriate scope.  For example, keeping a reference to a
>> request or response object in a static field, a session, or a
>> thread-local, will often result in the wrong object being used
>> later on.  This is especially evident under high-load
>> situations...
>>
>> - Chuck
>
> Okay, it looks like you put me on the right track. Just discovered
> that one of the servlets uses an instance variable to hold the
> request/response/session objects. Oy, and it was like that since
> 2008! Not positive this will resolve all the issues, but it's a
> clear bug. Thanks for your tip.

Here's another tip: run "findbugs" against your code. It will complain
about "class members in a Servlet" along with a zillion other things
that you might find will improve your code significantly.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+h2l4ACgkQ9CaO5/Lv0PBInwCePnYfQa0OHY+ZDFUJ1TqND3u0
Kn4AnRoxciJNHVQVNsb71oojwB5qeRc/
=cQfN
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

Konstantin Kolinko
In reply to this post by David Wall
2012/5/3 David Wall <[hidden email]>:

>
>
> On 5/2/2012 2:17 PM, Caldarale, Charles R wrote:
>>
>> Both this symptom and your earlier one about creating a session after a
>> response has been committed are representative of the kinds of errors seen
>> when a webapp stores references in an inappropriate scope.  For example,
>> keeping a reference to a request or response object in a static field, a
>> session, or a thread-local, will often result in the wrong object being used
>> later on.  This is especially evident under high-load situations...
>>
>>  - Chuck
>
>
> Okay, it looks like you put me on the right track. Just discovered that one
> of the servlets uses an instance variable to hold the
> request/response/session objects. Oy, and it was like that since 2008!  Not
> positive this will resolve all the issues, but it's a clear bug.  Thanks for
> your tip.
>

One more tip:
run with "org.apache.catalina.connector.RECYCLE_FACADES=true"

That will be more secure and you will be able to more easily detect
errors like this one.

http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html
http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Konstantin,

On 5/3/12 9:23 AM, Konstantin Kolinko wrote:
> One more tip: run with
> "org.apache.catalina.connector.RECYCLE_FACADES=true"

RequestFacade is a fairly lightweight object: it's only got a single
(reference) member so it's weight is something around 3 or 4 times the
size of a pointer.

Why isn't this setting enabled by default? Generating 32 bytes of
garbage during a request is fairly trivial and, as you say, improves
security (for a broken webapp) and helps identify apps that improperly
store the request somewhere like this.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+ioYgACgkQ9CaO5/Lv0PAVTACfXAtdih/SX5QKxeRNc9kBPj2j
1l0AniBXEOO3w8kDtzmIjBUIke+CoCea
=Ae+p
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

David Wall
In reply to this post by Christopher Schultz-2
Chris,

Thanks for the 'findbugs' tip.  I'm running it now in Eclipse and it has
indeed found real bugs and some good stylistic ideas as well.

David

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

David Wall
In reply to this post by David Wall
Just a quick update on these several threads of Tomcat 7 oddball
exceptions.  It looks to be as Chuck believed that it was a coding error
on our end that was causing this.  In particular, it was the no-no
misuse of instance variables in a controlling servlet.

Thanks for everyone's help!

David

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Pid
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

Pid
In reply to this post by David Wall
On 03/05/2012 19:54, David Wall wrote:
> Chris,
>
> Thanks for the 'findbugs' tip.  I'm running it now in Eclipse and it has
> indeed found real bugs and some good stylistic ideas as well.

If you like that, try Sonar.

 http://www.sonarsource.org/


p


--

[key:62590808]


signature.asc (964 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

ravi kant chaturvedi
i got the proper solution for my problem, so i do not require more mails from this list.

please stop the mail, because this is spoiling my mail box.

Thanks and Regards
----------------------------
Ravi Kant Chaturvedi


________________________________
 From: Pid <[hidden email]>
To: Tomcat Users List <[hidden email]>
Sent: Friday, 4 May 2012 12:24 PM
Subject: Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
 
On 03/05/2012 19:54, David Wall wrote:
> Chris,
>
> Thanks for the 'findbugs' tip.  I'm running it now in Eclipse and it has
> indeed found real bugs and some good stylistic ideas as well.

If you like that, try Sonar.

http://www.sonarsource.org/


p


--

[key:62590808]
Pid
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

Pid
On 5 May 2012, at 05:11, ravi kant chaturvedi <[hidden email]> wrote:

> i got the proper solution for my problem, so i do not require more mails from this list.
>
> please stop the mail, because this is spoiling my mail box.

If you don't want any more mail from this list, unsubscribe from the
mailing list. It's not like we're all personally including you on
every email we send.


p


>
> Thanks and Regards
> ----------------------------
> Ravi Kant Chaturvedi
>
>
> ________________________________
> From: Pid <[hidden email]>
> To: Tomcat Users List <[hidden email]>
> Sent: Friday, 4 May 2012 12:24 PM
> Subject: Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
>
> On 03/05/2012 19:54, David Wall wrote:
>> Chris,
>>
>> Thanks for the 'findbugs' tip.  I'm running it now in Eclipse and it has
>> indeed found real bugs and some good stylistic ideas as well.
>
> If you like that, try Sonar.
>
> http://www.sonarsource.org/
>
>
> p
>
>
> --
>
> [key:62590808]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

André Warnier
Pid * wrote:

> On 5 May 2012, at 05:11, ravi kant chaturvedi <[hidden email]> wrote:
>
>> i got the proper solution for my problem, so i do not require more mails from this list.
>>
>> please stop the mail, because this is spoiling my mail box.
>
> If you don't want any more mail from this list, unsubscribe from the
> mailing list. It's not like we're all personally including you on
> every email we send.
>
.. and all our apologies for spoiling your mailbox.  Believe us, it was entirely
unintentional. We can only hope that you forgive us.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap

Christopher Schultz-2
In reply to this post by ravi kant chaturvedi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ravi,

On 5/5/12 12:10 AM, ravi kant chaturvedi wrote:
> i got the proper solution for my problem, so i do not require more
> mails from this list.
>
> please stop the mail, because this is spoiling my mail box.

Pro tip: filter your email. It's what all the cool kids are doing
these days.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+oOBEACgkQ9CaO5/Lv0PDruACfXdlNov5EOvbRMogT+A7aUcu3
ed0AmQEymREUPDcvAF4CJzwjyK7UsFLF
=QqeW
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...