tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: memory leak with shrinking thread pools
Date Thu, 12 Apr 2007 14:29:46 GMT
Peter Rossbach wrote:
> Hi Filip,
>
>
> I have test your patch with my comet testclient.  It seems not 
> working.  The RequestProcessors JMX Objects aren't deregistered:
So far the patch is only for NIO, I will make it for APR and JIO today.
>
> Access Log:
>
> '127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/?null - - - 200  0.001
> '127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'connect' 
> 'TestClient0' - 200 '9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.001
> '127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'send' 
> 'TestClient0' '0-1176383146864' 200 
> '9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.002
> '127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'connect' 
> 'TestClient0' - 200 '9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.000
> '127.0.0.1:30014' 2007-04-12 13:05:51 /cometchat/chat?null 
> 'disconnect' 'TestClient0' - 200 
> '9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.001
>
> Server.xml config:
> ...
>     <Listener 
> className="org.apache.catalina.core.AprLifecycleListener" 
> SSLEngine="on" />
>     <Listener className="org.apache.catalina.core.JasperListener" />
> ...
>     <Service name="Catalina">
>         <Connector port="30011"
>                    URIEncoding="UTF-8"
>                    useExecutor="false"
>                    minSpareThreads="150"
>                    maxSpareThreads="150"
>                    maxThreads="150"
>                    connectionTimeout="300000"
>                    
> protocol="org.apache.coyote.http11.Http11AprProtocol"/>
>                    pollerSize="1024" />
>         <Connector port="30014"
>                    URIEncoding="UTF-8"
>                    useExecutor="false"
>                    minSpareThreads="150"
>                    maxSpareThreads="150"
>                    maxThreads="150"
>                    connectionTimeout="300000"
>                    
> protocol="org.apache.coyote.http11.Http11NioProtocol"/>
> ...
> </Server>
>
>
> With NIO I see the following event log:
>
> Event received connect BEGIN
> Getting handler for action connect
> New client connected TestClient0
> Event received send BEGIN
> Getting handler for action send
> Sending message from TestClient0 message: 0-1176383115466
> Disconnecting client (commit)
> Sent 1 messages to connected client TestClient0
> Event received connect BEGIN
> Getting handler for action connect
> Client reconnected: TestClient0
> Event received disconnect BEGIN
> Getting handler for action disconnect
> Closing empty room 0
> Disconnecting client (commit)
> Remove client TestClient0. 0 clients remain.
>
> After every test  three more JMX RequestProcessors are registered.
> I don't see the Comet END events like the APR Connector send to my 
> ChatServlet.
What steps do you take to see an "END" event?
Filip
>
> APR Connector Log
>
> Event received connect BEGIN
> Getting handler for action connect
> New client connected TestClient0
> Event received send BEGIN
> Getting handler for action send
> Sending message from TestClient0 message: 0-1176383857840
> Disconnecting client (commit)
> Sent 1 messages to connected client TestClient0
> Event received connect END
> Getting handler for action connect
> Disconnecting client TestClient0
> Event received connect BEGIN
> Getting handler for action connect
> Client reconnected: TestClient0
> Event received disconnect BEGIN
> Getting handler for action disconnect
> Closing empty room 0
> Disconnecting client (commit)
> Remove client TestClient0. 0 clients remain.
> Event received connect END
> Getting handler for action connect
>
> Regards
> Peter
>
>
> Am 12.04.2007 um 05:48 schrieb Filip Hanik - Dev Lists:
>
>> Here is a revised patch for the memory leak.
>> One thing I noticed is that it goes a little farther than I think it 
>> does.
>> Since every request processor gets registered with JMX, I just 
>> couldn't find a spot where it was unregistered.
>> And since the name was dynamic, ie based on the "count++" variable, 
>> there would be no way to unregister unless you knew the name.
>>
>> http://people.apache.org/~fhanik/mem-leak-diff.patch
>>
>> I suspect, that this memory leak also exists with the old thread 
>> pool, when you restart the endpoint in a running environment. At that 
>> time, all the threads get recycled, and most stuff gets unregistered, 
>> except the RequestInfo objects.
>>
>> In this patch, I modified the usage of the recycledProcessor cache, 
>> to have a limit, and also to deregister objects should it be needed.
>>
>> Personally, I'm still really confused about how everything gets 
>> registered with the MBean server and then holds hard references into 
>> the code itself.
>> On one note, I think the JMX stuff could simply have weak references, 
>> as in my old patch, but that could have other consequences.
>>
>> Please comment on this patch, I'm planning on committing it tomorrow 
>> (Thursday) as it seems to work well for me.
>>
>> Filip


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


Mime
View raw message