Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4C59F2D8.6070704@ice-sa.com>
Date: Thu, 05 Aug 2010 01:08:08 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat 6 does not respond or freeze after startup
References: <4C5738BA.3040302@normad.de> <4C573B24.8060201@apache.org>
 <4C58701B.3050603@normad.de> <4C587565.9020009@apache.org>
 <4C5884C9.7060605@normad.de>
 <99C8B2929B39C24493377AC7A121E21F9900F9C90E@USEA-EXCH8.na.uis.unisys.com>
 <4C588E37.9020301@normad.de>
 <99C8B2929B39C24493377AC7A121E21F9900F9C98E@USEA-EXCH8.na.uis.unisys.com>
 <4C58FE77.2080805@normad.de>
 <99C8B2929B39C24493377AC7A121E21F9900F9CE14@USEA-EXCH8.na.uis.unisys.com>
 <4C59D39D.1090307@normad.de> <4C59D79E.6000707@ice-sa.com>
 <4C59DF2E.8070206@normad.de>
In-Reply-To: <4C59DF2E.8070206@normad.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

T. Gau wrote:
>  Hello,
> 
> the CLOSE_WAIT connections are persistent (waiting 10+min now). The 
> FIN_WAIT counterparts from the browser disapear after some time.
> 
> As a reminder: The Tomcat installation is "untouched". No configuration 
> and no deployed applications besides these allready packaged with Tomcat.
> 
> 

Ok. But from the netstat dislay below, it looks as if a number of processes *local to the 
server* and with PID's 2049,2050,1992,1991 etc.. /have/ connected to Tomcat on port 8080.
What are these processes, and are they still alive when you take this netstat screenshot ?

Can you briefly remind us of what kind of request to Tomcat these clients are issuing, and 
what happens in them while they wait/don't wait for a response ?

(A long time ago, I got some "ps.exe" program - probably in a Windows/NT Toolkit - which 
is easier than the Task Manager to look this up and cut/paste.
Apparently still available in some form : 
http://technet.microsoft.com/en-us/sysinternals/bb795532.aspx
)


> Kind regards,
> 
> T. Gau
> 
> 
> Andr� Warnier schrieb am 04.08.2010 23:11:
>> Hi T.
>>
>> T. Gau wrote:
>>>  Hello,
>>>
>>> I have executed 'netstat -anopb tcp' with the following result:
>>> TCP    0.0.0.0:8009           0.0.0.0:0              LISTENING        
>>> 3436    [java.exe]
>>> TCP    0.0.0.0:8080           0.0.0.0:0              LISTENING        
>>> 3436    [java.exe]
>>> TCP    127.0.0.1:8005         0.0.0.0:0              LISTENING        
>>> 3436      [java.exe]
>>>
>>> I could not find another listening port for java.exe.
>>
>> The above is perfectly normal and classical.  It shows
>> - a listening port 8080, for the HTTP Connector
>> - a listening port 8009, for the AJP Connector
>> - a listening port 8005, for the Tomcat shutdown connector
>>
>>
>>>
>>> BUT the requests to the frozen Tomcat results into
>>> TCP    127.0.0.1:8080         127.0.0.1:2049         CLOSE_WAIT    
>>> 3436    [java.exe]
>>> TCP    127.0.0.1:8080         127.0.0.1:2050         CLOSE_WAIT    
>>> 3436    [java.exe]
>>> TCP    127.0.0.1:8080         127.0.0.1:1992         CLOSE_WAIT    
>>> 3436    [java.exe]
>>> TCP    127.0.0.1:8080         127.0.0.1:1991         CLOSE_WAIT    
>>> 3436    [java.exe]
>>> TCP    127.0.0.1:8080         127.0.0.1:2051         CLOSE_WAIT    
>>> 3436    [java.exe]
>>> TCP    127.0.0.1:8080         127.0.0.1:1990         CLOSE_WAIT    
>>> 3436    [java.exe]
>>> TCP    127.0.0.1:8080         127.0.0.1:1989         CLOSE_WAIT    
>>> 3436    [java.exe]
>>> TCP    127.0.0.1:8080         127.0.0.1:2043         CLOSE_WAIT    
>>> 3436    [java.exe]
>>> TCP    127.0.0.1:8080         127.0.0.1:2042         CLOSE_WAIT    
>>> 3436    [java.exe]
>>> Any ideas what happens here?
>>>
>>
>> That is more interesting. If the situation above is transitory (just 
>> lasts a few seconds), then it might be normal.  If the situation above 
>> persists for a long tine, then it shows that Tomcat (or something 
>> within Tomcat) is not properly closing its end of client sockets, and 
>> that the objects containing these sockets are lingering on the Heap, 
>> waiting to be collected.
>> I'm sure someone else on this list could suggest a scenario where a 
>> badly-behaved application could achieve this.
>> (or a very large keepAlive setting ?)
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 


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