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 31018] New: - Race condition in SystemLogHandler.java
Date Thu, 02 Sep 2004 15:55:32 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=31018>.
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=31018

Race condition in SystemLogHandler.java

           Summary: Race condition in SystemLogHandler.java
           Product: Tomcat 5
           Version: 5.0.28
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Unknown
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: rrg@panix.com


The org.apache.tomcat.util.log.SystemLogHandler class (source code in
jakarta-tomcat-connectors) handles, among other things, capturing of
System.out and System.err so that they can be redirected to an
application's log file.  It makes use of another class (CaptureLog) to
hold the captured data, and maintains a stack of unused CaptureLog
instances to avoid creating new ones where possible.
                                                                                
This "reuse" stack is global to the class and it looks like the use of
it is not thread-safe.  The startCapture() method acquires a
CaptureLog() this way:
                                                                                
    if (!reuse.isEmpty()) {
        log = (CaptureLog)reuse.pop();
    } else {
        log = new CaptureLog();
    }
                                                                                
There's a race between the call to isEmpty() and the call to pop().
We've been able to reliably elicit a java.util.EmptyStackException at
this point with an application under heavy load.
                                                                                
Replacing the above code with
                                                                                
    synchronized (reuse) {
        log = reuse.isEmpty() ? new CaptureLog() : (CaptureLog)reuse.pop();
    }
                                                                                
eliminates the problem (with no effect on performance that we could
observe).
                                                                                
An alternative approach might be to catch the (rare)
EmptyStackException and treat it as equivalent to the isEmpty==true
case, but this seems cleaner.
                                                                                
There would seem to be no need to synchronize the code that pushes
old CaptureLog instances onto the reuse stack since java.util.Stack
is already synchronized.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message