What's happening is that in method traceSystem.getTrace() it adds a
new trace to the hashmap for each module that calls this method. We
see a module corresponding to each H2 session going through this call,
so the hashmap just keeps getting bigger and bigger with no removes
when connections are closed.
What's even worse is we suspect this is also causing a creep up in the
permgen memory pool (because we suspect that hashmap keys are
intern'd) , which is (by default) 64MB. So in our case, the permgen
pool blew up before the regular heap. Which led to a lot of head
scratching because it's much harder to see what's going on in permgen
than in the normal heap.
Cheers,
Milt
Thanks a lot for your help! I will add a test case for this problem.
However so far I can not make it go out of memory with my test, even I
am opening and closing a lot of connections. Anyway, I will fix it.
Thomas
I should have clarified that it might actually take a long time (days)
before you actually run out of memory, because the amount of mem
leaked per new connection is not large. We found this leak using
yourkit java profiler, while we were looking for leaks in general.
I also use the YourKit Java Profiler, a great tool in my view. I will
fix this problem of course, even if the leak is not that big.
Thanks a lot!
Thomas
On 5/3/07, mctozzy <mct...@gmail.com> wrote:
>
> >