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=27537>.
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=27537

a likely serious error in the ThreadPool.java

           Summary: a likely serious error in the ThreadPool.java
           Product: Tomcat 5
           Version: 5.0.19
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: Connector:Coyote
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


ThreadPool.java in jakarta-tomcat-
connectors\util\java\org\apache\tomcat\util\threads has a likely serious bug.
my tomcat can not afford to high load throughput when we put my jetspeed portal 
on client production environment. It can not pass client stress testing when we 
simulate 300 concurrent users.

I carefully read the implementation of PoolTcpEndPoint.java, and 
ThreadPool.java. I found a bewildering smell in the "run" method of 
ControlRunnable class.

.......
                            if (_shouldRun) {
                                if (_toRun != null) {
                                    _toRun.runIt(t.getThreadData(p));
                                } else if (toRunRunnable != null) {
                                    toRunRunnable.run();
                                } else {
                                    if (ThreadPool.log.isDebugEnabled())
                                    ThreadPool.log.debug("No toRun ???");
                                }
                            }
                        } catch (Throwable t) {
                            ThreadPool.log.error(sm.getString
                                ("threadpool.thread_error", t, toRun.toString
()));
                            /*
                             * The runnable throw an exception (can be even a 
ThreadDeath),
                             * signalling that the thread die.
                             *
                            * The meaning is that we should release the thread 
from
                            * the pool.
                            */
                            shouldTerminate = true;
                            shouldRun = false;
                            p.notifyThreadEnd(this);
                        } finally {
                            if (_shouldRun) {
                                shouldRun = false;
                                /*
                                * Notify the pool that the thread is now idle.
                                 */
                                p.returnController(this);
                            }
                        }

when the thread which attach to the controlrunnable object exits due to some 
exception from _toRun.runIt(t.getThreadData(p))(for example, socket timeout, or 
other exceptions), it will execute p.notifyThreadEnd(this) in "catch (Throwable 
t)" block and also p.returnController(this) in finally block. it will cause bad 
behavior, I think.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to