On May 22, 2013, at 9:09 AM, Christopher Schultz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Mark, > > On 5/21/13 2:38 PM, Mark Thomas wrote: >> On 21/05/2013 19:01, Michael-O wrote: >>> Mark, >>> >>> I did receive an answer to the issue, citing your findings. See >>> verbatim copy below: >>> >>> Hi Michael, >>> >>> I received the following update from our developer: >>> >>> ********************************************************** The >>> theoretical problem is that the thread is holding the app class >>> loader so it remains reachable and the app is never unloaded. So >>> if the user loads and unloads the app, the app classes remain in >>> memory. Subsequent loading and unloading of the app will not get >>> pinned in memory as the thread is already running so the >>> subsequent loading and unloading will not cause additional class >>> loaders to be pinned. It is a fixed size memory leak. It does not >>> grow. >>> >>> The thread suggests setting the context class loader to be the >>> parent of the default context class loader. This may work in >>> Tomcat but it's pretty random. I am researching the problem to >>> determine what if anything the driver should do to work across >>> all containers. A Tomcat specific fix is not acceptable. >> >> Almost but not quite. The correct fix is to set the context class >> loader of the Thread to the class loader that loaded the Driver > > +1 > >> or, alternatively, the class loader that loaded the thread class. > > Do you mean java.lang.Thread (primordial)? Or whatever subclass they > are using? Maybe it would be more accurate to say "the ClassLoader of > the runnable being run" which covers thread-subclasses or standard > Runnables being run by a standard Thread.
Or why not just java.sql.DriverManager.class.getClassLoader()? Since drivers are always stored in the DriverManager regardless of what class loader they're loaded in (hence why you shouldn't put the driver in WEB-INF/lib), isn't the alway-correct solution to use the class loader that loaded the DriverManager for this thread? > >>> As Mark Thomas pointed out it is critical that the driver is >>> loaded in the boot or system or container class loader, not the >>> app class loader. If the driver is in the app class loader then >>> when the app is unloaded the driver also should be unloaded. >>> Unfortunately this doesn't work. The driver itself remains >>> reachable so the app class loader is reachable so the app is >>> never unloaded. At present there is no general way to solve this >>> problem. The necessary hooks are added in JDK 8. >> >> I'd agree to this point. >> >>> Most users put the driver in the container, not the app, so this >>> is rarely a problem. >> >> I don't agree with this. I often see this with JDBC drivers which >> is why Tomcat has a pile of code specifically to unpick the mess >> this creates. > > They are missing the point: the leak cannot be avoided, even if the > driver is (correctly) placed in the container-level ClassLoader and > not the application. It's frustrating when driver authors take so long > so understand what is going on and how easy (and reasonable) it is to > fix the problem. > >>> ********************************************************** >>> >>> I will certainly have to fill out a bug to have it investigated >>> officially. >> >> That is good news. >> >>> Seems like they understood the problem. But I do doubt that this >>> is a fixed size moemory leak. >> >> I think the point they are trying to make is that it is only the >> first instance of the web application to be unloaded that will be >> pinned in memory. Subsequent reloads won't trigger a leak. That is >> correct. > > That is little solace to folks who have more Class objects than just > about anything else. With a huge number of support libraries being > used to operate a fairly lean transaction-processing system, a single > reload could bust the heap and/or PermGen. > > Just because it's a fixed-size memory leak doesn't mean it isn't worth > fixing. :( Agreed. Nick --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
