Re: memory leak with shrinking thread pools

Thu, 12 Apr 2007 08:07:20 -0700 

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to