tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Rossbach ...@objektpark.de>
Subject Re: memory leak with shrinking thread pools
Date Thu, 12 Apr 2007 15:06:54 GMT
Hi Filip,

I have testet with NIO and the memory leak is still there.

Peter



Am 12.04.2007 um 16:29 schrieb Filip Hanik - Dev Lists:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message