tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 37803] New: - MessageBytes makes it easy to have state problems
Date Mon, 05 Dec 2005 23:07:54 GMT
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: doug_rand@percussion.com


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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message