It seems that this memory leak happens only once. I guess the first deploy (the one which will force the creation of the background Java2D thread) will hang around forever, but subsequent redeploys will be correctly cleaned-up.
Also, what leaks is the classloader. Only static variables and class definitions will be kept in memory. So, you will only get an OutOfMemoryError (and it will be a PermGen error) if your container has too little permgen memory allocated, your application is realy huge (in class number), or you keep very large objects in static vars, since it must break with only two instances of the application. That said... there's nothing like a working (err, breaking) test case to prove a point! On Tue, May 25, 2010 at 6: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 > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-tp2226987p2230796.html > Sent from the Wicket - Dev mailing list archive at Nabble.com. >
