Peter Rossbach wrote:
HI Filip,
with your last checkin my trace changed but leak is there. Also I got
a exception too:
yes, still working on it,
Filip
12.04.2007 17:20:30 org.apache.tomcat.util.net.NioSelectorPool
getSharedSelector
INFO: Using a shared selector for servlet write/read
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-1176391230388
Disconnecting client (commit)
Sent 1 messages to connected client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received connect END
Getting handler for action connect
Disconnecting client TestClient0
Disconnecting client (commit)
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 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-1176391294275
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.
Exception in thread "http-30014-2" java.lang.NullPointerException
at
org.apache.tomcat.util.net.NioEndpoint$Worker.run(NioEndpoint.java:1863)
at java.lang.Thread.run(Thread.java:613)
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-1176391394010
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.
Exception in thread "http-30014-1" java.lang.NullPointerException
at
org.apache.tomcat.util.net.NioEndpoint$Worker.run(NioEndpoint.java:1863)
at java.lang.Thread.run(Thread.java:613)
Regards
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
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]
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 269.2.0/757 - Release Date: 4/11/2007 5:14 PM
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
