On Tue, May 25, 2010 at 4:57 PM, Alex Objelean <alex.objel...@gmail.com>wrote:
> > James, thank you very much for such a detailed description. I appreciate > your > effort and I'm sure this experience helped me to learn a lot of new things. > Nevertheless, I would like to clarify few things: > > Here is a definition of memory leak: "If a program holds a reference to a > heap chunk that is not used during the rest of its life, it is considered a > memory leak because the memory could have been freed and reused. GC won't > reclaim it due to the reference being held by the program." > I agree, your example proved that WicketApplication instance is used by > InheritableThreadLocal (that is exactly what ITL does). Have you managed to > find it even after the servlet container was stopped? Isn't it important to > prove that the 'WicketApplication' instance outlives the servlet container > and holds a reference to a heap chunk? > To make it simpler to test, I have changed a little bit your quickstart, > making the WicketApplication intance insanely big, by adding a very large > object (50MB). My expectation was, in order to prove the memory leak, to > see > that the physical memory used by the JVM increases by 50MB after each > restart, or at least steadily grow. You can check this by monitoring the > 'Local' entry and the memory details from the right pane of the VisualVM > window. > But the actual behavior seems to be different: performing several times > the same flow: "start the server->load the home page->stop the server" > doesn't increase the heap memory usage. The memory usage comes back to > normal after each restart. > > I do not want to draw the conclusion, because I could have a wrong > understanding of what a 'memory leak' is and how to prove it correctly. > That > is why, I'm kindly asking you (or anybody else) to interpret my findings. > > Thank you! > Regards, > Alex Objelean > > PS: by the way, I'm using jdk 1.6.0_13-b03 if it does make any difference > > Alex, this isn't leaking into sessions that are written to disk, so it would not persist through a restart. The original reporter said specifically that this happens on redeploys *without a restart*. I've reverted this to a regular ThreadLocal for 1.4.10. -- Jeremy Thomerson http://www.wickettraining.com
