I spent awhile analyzing why our application was having a problem. We have an unusual case - a product that was its own web server adapted to live under JBoss/Tomcat. Now that we're running under Tomcat I decided that some new browser UI should use JSF, but after I was running with JSF I started having occasional problems with exceptions. After tracking this down I finally understood the problem. We are probably (I'll be tracking this down next) accessing an HttpServletRequest outside of the standard loop that the dispatcher puts it through. I will grant a priori that this is invalid and we shouldn't be doing so. However, the underlying issue is that methods in the request object end up calling MessageBytes.toString. Our particular case calls the getScheme() method. This wouldn't be a problem, but after recycle is called, the MessageBytes object is "null". But if you call toString(), it returns false from isNull, and that *is* a problem. My broken app should not be able to put this underlying data structure into an invalid state by calling a getter. As a result of no longer being "null" from the isNull perspective, the dispatcher no longer sets the scheme on the new request, which breaks the next request that uses that request object. I'd suggest two changes: 1) recycle the request right before use to limit the extent of the threading window 2) fix the toString method to not change the object's state for the null case For #2, something like this might suffice, and is much safer than the current code: public String toString() { if( hasStrValue ) return strValue; switch (type) { case T_CHARS: hasStrValue=true; strValue=charC.toString(); return strValue; case T_BYTES: hasStrValue=true; strValue=byteC.toString(); return strValue; } return null; }
I disagree. Tomcat should be more robust than to allow a rogue webapp to place it into an inconsistant state.
I've committed a slightly modified version of your patch to SVN trunk. Hopefully it will make the cutoff to be included in 5.5.14.
(In reply to comment #1) > I disagree. Tomcat should be more robust than to allow a rogue webapp to > place it into an inconsistant state. Oh cool :) Whatever you want Bill. Yet another patch which will not be in my tree, I suppose.
(In reply to comment #3) > Oh cool :) Whatever you want Bill. Yet another patch which will not be in my > tree, I suppose. After reviewing it, I'm actually taking in the patch, since it's a decent cleanup. (In reply to comment #1) > I disagree. Tomcat should be more robust than to allow a rogue webapp to > place it into an inconsistant state. There's a mode like that, and it happens using the security manager. This bug report is actually a user list question.