tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 56381] ServletRequest can be modified by Multiple Threads
Date Thu, 10 Apr 2014 13:31:41 GMT

--- Comment #1 from Jess Holle <> ---
I am perfectly aware that the servlet API makes no guarantees about thread
safety of the [Http]ServletRequest interface or implementations thereof.

I also understand that providing general thread-safety in implementation would
have performance and/or implementation complexity costs that may not be

As such I've been calling getParameterMap() and the like in my first servlet
filter -- thus allowing other threads to access this data after this point
without issues up until the request thread completes work on the request. 
There are some really good use cases for this sort of thing -- e.g. monitoring
the state of all in-flight requests.

The real issue here, however, is what occurs if these APIs are invoked after
the request thread completes its request work.  It was clear to me that the
other threads could get bad data in such a case -- and I'm fine with that. 
They should have made a copy of the data if the data acquisition is more than
just a "best effort" affair.  What was not at all clear is that recycle
behavior could allow any bit of code to toss ServletRequest objects to other
threads, call methods against these objects too late and completely corrupt
later servlet requests!  That's a real safety issue in a larger application.

For my own monitoring code I've added a read/write lock that ensures that there
is no possible race condition between request completion and switching over to
a copy of the ServletRequest data.  That's well and good.  What I can't do,
however, is keep any other developer from doing something stupid and corrupting
unrelated requests, which is a troubleshooting nightmare.

I suppose I could change my servlet filter implementation to use a wrapped
ServletRequest object with built-in read/write locking that switched the
underlying ServletRequest object to null at the end of the request.  That's a
lot of workaround code to avoid intrinsic recycle issues, though.

You are receiving this mail because:
You are the assignee for the bug.

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

View raw message