You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David Wall <d....@computer.org> on 2012/05/02 22:56:37 UTC
Tomcat 7 - No modifications are allowed to a locked ParameterMap
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/5/3 David Wall <d....@computer.org>:
>
>
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Posted by André Warnier <aw...@ice-sa.com>.
Pid * wrote:
> On 5 May 2012, at 05:11, ravi kant chaturvedi <rk...@yahoo.com> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Posted by Pid * <pi...@pidster.com>.
On 5 May 2012, at 05:11, ravi kant chaturvedi <rk...@yahoo.com> 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 <pi...@pidster.com>
> To: Tomcat Users List <us...@tomcat.apache.org>
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Posted by ravi kant chaturvedi <rk...@yahoo.com>.
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 <pi...@pidster.com>
To: Tomcat Users List <us...@tomcat.apache.org>
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]
Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Posted by Pid <pi...@pidster.com>.
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]
Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Posted by David Wall <d....@computer.org>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Posted by David Wall <d....@computer.org>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: David Wall [mailto:d.wall@computer.org]
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Posted by David Wall <d....@computer.org>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: David Wall [mailto:d.wall@computer.org]
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Posted by David Wall <d....@computer.org>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org