Filip Hanik - Dev Lists wrote:
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.

It needs to be unregistered when (= if) it is discarded. However, the monitoring needs were there when the processor was associated with a thread. Now with comet and executors, this is not the case. So it may be a good idea to think and see if a similar monitoring capability with a different implementation could be provided in the future (otherwise, it should probably go away).

http://people.apache.org/~fhanik/mem-leak-diff.patch

In the immediate future, I think it's the best solution.

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.

It should have a mechanical limit already: it's the maximum amount of concurrent connections + the maximum amount of comet connections. Giving it a lower limit would mean creating processors, which is expensive. I suggest adding a parameter.

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.

IMO, weak references are too weird, plus it would not solve any registration issue.

Please comment on this patch, I'm planning on committing it tomorrow (Thursday) as it seems to work well for me.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to