DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12322>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12322

Port *.8080 in LISTEN state after tomcat shutdown

           Summary: Port *.8080 in LISTEN state after tomcat shutdown
           Product: Tomcat 4
           Version: 4.0.4 Final
          Platform: Sun
        OS/Version: Solaris
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: Catalina
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


After shutting down tomcat with $CATALINA_HOME/bin/shutdown.sh, netstat shows 
that port *.8080 is in LISTEN state. This means that tomcat cannot be restarted 
until some kind of timeout occurs (around 10-15 minutes). Tomcat throws an 
IOException from HttpConnector/../DefaultServerSocketFactory (the one in 
catalina/net in catalina.jar) upon startup until the timeout occurs.

I have verified that there is no "java" process running (using "ps -ef" 
and "/usr/ucb/ps auxww"). There is no service for 8080 defined in /etc/services 
(inetd paranoia).

This is with jakarta-tomcat-4.0.4-LE-jdk14, j2sdk1.4.0_01, Solaris 2.8, two CPU 
Sun server.

I cannot reproduce the problem with a simple C program or a simple Java 
program; in both cases, ports go to TIME_WAIT state upon application exit. 
Setting SO_REUSEADDR in the C program allows it to be restarted (and the bind 
to succeed). It seems that Java sockets set SO_REUSEADDR by default, under 
Solaris at least. 

My understanding is that for a port to be in LISTEN state, there must be a
process (or kernel?) thread running that is bound to the port.  My instinctive 
feeling is there is a JRE thread running that is waiting to GC the tomcat 
ServerSocket object, but I cannot see any such process. I can't reproduce it, 
and I've tried calling System.gc() (desperatation!). The issue makes no sense
to me.

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

Reply via email to