https://issues.apache.org/bugzilla/show_bug.cgi?id=56381
--- Comment #1 from Jess Holle <je...@ptc.com> --- 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 appropriate. 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
