tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <tom...@alsutton.com>
Subject Re: DO NOT REPLY [Bug 33339] - Shutdown script down not work
Date Wed, 02 Feb 2005 15:00:07 GMT

A few points;

1) This bug is also on SuSE Enterprise Server 8 as welll as FC2.

2) The sentance "which seems to show there are a lot of threads
 waiting on an object" does make sense if you've delt with threaded
programming and strack traces before. All of the threads with
Object.wait() listed at the top are held in the wait() method of an
object (i.e. the thread is waiting on an object). This is a term which
comes from Suns own JavaDoc for the Object class and can be seen at
http://java.sun.com/j2se/1.3/docs/api/java/lang/Object.html.

Although a number of the threads are daemon threads, and thus don't need
to exit before the JVM exits, it's usually safe programming to allow
the thread to exit gracefully to ensure the correct release of any
resources.


3) Cygwin is definatley NOT a good platform for testing Linux bugs on.
Cygwin is a layer that converts Unix calls into their Windows
equivalents, but it does not have Linux underneath and therefore does
not represent the threading, networking, and scheduling characteristics
of a Linux machine. 


4) Do you want to tell the Fedora guys that the Tomcat developers
official view of Fedora Core 2 is that its' a "crappy distro"?


5) Do you expect me to re-install my system just to get Tomcat working?,
It's easier to replace Tomcat with Jetty than it would be to resintall
my machine with one of the distros that you don't consider "crappy"
(mind you I would have thought Novell would be interested to hear it if
you want to call SLES 8 crappy as well).



Now I'd like to help resolve this, but at the moment all I'm seeing is a
wall of "not interesting, can't be bothered, lets' mark it as invalid
because I can't reproduce on my own personal setup". Which kinda
worries me about how many other bugs have been treated in this manner
and the bug reporters just gave up hope of getting things fixed.

Regards,

Al.


bugzilla@apache.org wrote on 02.02.2005, 12:15:55:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> .
> 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=33339
> 
> 
> remm@apache.org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|REOPENED                    |RESOLVED
>          Resolution|                            |INVALID
> 
> 
> 
> 
> ------- Additional Comments From remm@apache.org  2005-02-02 12:15 -------
> My post to this bug got lost somehow. The code indicates that shutdown of the JK
> connector is failing in the unlock accept process. This code has been there
> unchanged (and identical) for years in both JK and HTTP, and hasn't caused any
> problems. If you're not using JK, you can try disabling it.
> 
> BTW, don't write statements like "which seems to show there are a lot of threads
> waiting on an object". This doesn't make any sense, and makes the credibility of
> the report go down. Stick to reproduceable facts if you are not aware of
> implementation details. The only thread which matters here is:
> 
> "main" prio=1 tid=0x0805bda8 nid=0x33b6 runnable [bfffc000..bfffd618]
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> 	- locked  (a java.net.PlainSocketImpl)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> 	at java.net.Socket.connect(Socket.java:452)
> 	at java.net.Socket.connect(Socket.java:402)
> 	at java.net.Socket.(Socket.java:309)
> 	at java.net.Socket.(Socket.java:153)
> 	at org.apache.jk.common.ChannelSocket.unLockSocket
> (ChannelSocket.java:460)
> 	at org.apache.jk.common.ChannelSocket.pause(ChannelSocket.java:272)
> 	- locked  (a org.apache.jk.common.ChannelSocket)
> 	at org.apache.jk.server.JkMain.pause(JkMain.java:677)
> 	at org.apache.jk.server.JkCoyoteHandler.pause(JkCoyoteHandler.java:208)
> 	at org.apache.catalina.connector.Connector.pause(Connector.java:933)
> 	at org.apache.catalina.core.StandardService.stop
> (StandardService.java:491)
> 	- locked  (a [Lorg.apache.catalina.connector.Connector;)
> 	at org.apache.catalina.core.StandardServer.stop
> (StandardServer.java:717)
> 	at org.apache.catalina.startup.Catalina.stop(Catalina.java:586)
> 	at org.apache.catalina.startup.Catalina.start(Catalina.java:561)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:324)
> 	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271)
> 	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409)
> 
> I tested this on Cygwin with startup.sh and shutdown.sh, with the default Tomcat
> configuration. Honestly, I don't see what it changes. One thing is certain: no
> developer will install the crappy distro you're using just for the sake of
> testing this. FC 3 is at least decent ... I will eventually install Tomcat on my
> Ubuntu.
> 
> When you file a bug, if developers cannot reproduce it, you need to explain how
> to reproduce it. If it still fails, or there's no possibility of reproducing,
> then sorry, there's no other way than try to find where the problem comes from,
> post to tomcat-user, or use another product if you think the problem is too
> serious. Given your attitude, I will not miss you ;)
> 
> -- 
> 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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

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