tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: memory leak with shrinking thread pools
Date Thu, 12 Apr 2007 10:14:18 GMT
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message