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 29907] - connector without accept thread (was: hanging during SSL negotiation)
Date Wed, 03 Nov 2004 09:27:38 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=29907>.
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=29907

connector without accept thread (was: hanging during SSL negotiation)

hauser@acm.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|Normal                      |Enhancement



------- Additional Comments From hauser@acm.org  2004-11-03 09:27 -------
It seems that we have found the solution (keep the fingers crossed  ;) ):
Apparently, Redhat 9. was the first Redhat Release that uses the new Posix
 Threads (NPTL), backported by Redhat from 2.6 Kernel to 2.4
Unfortunately, this appears to be buggy (e.g. CommunigatePro also has not been
"cleared" for redhat)

How to fix:
> mv /lib/tls /lib/tls.unused
> ldconfig
> catalina.sh restart

--> this brings back the old, classic Linux-Thread Implementation - slower, but
hopefully more robust.

When doing less /proc/PID/maps
no more shared objects from /lib/tls should be visible

The affected system as per "uname -a":
Linux myhost 2.4.20-30.9 #1 Wed Feb 4 20:44:26 EST 2004 i686 i686 i386 GNU/Linux

Wild enhancement suggestion to prevent similar stability nightmares in the future:
=======================================================================
(admitted, it is not really Tomcat's task to fix operating system bugs on the
application level, but if it is easy why not doing it anyway)

Idea how this could work:
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:616)

                       synchronized (this) {
                            while (!shouldRun && !shouldTerminate) {
                                this.wait();
                            }
                            _shouldRun = shouldRun;
                            _shouldTerminate = shouldTerminate;
                            _toRun = toRun;
                        }

Why could this not only wait to be notified about "work", but also perhaps wake
up every minute once by itself (and if another thread is already working going
immediately back to sleep since it cannot get the synchronized object.)
If that was possible, a big warning should be printed (provided one can detect
whether the thread woke up by itself instead of being notified) that tomcat is
covering up for underlying OS problems and the Sys-Admin better get informed
about possible patch...

What do you think?

---------------------------------------------------------------------
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