DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=37803>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37803 Summary: MessageBytes makes it easy to have state problems Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] 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; } -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
