-----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. >> 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. :( - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRnNGtAAoJEBzwKT+lPKRY6GUP/02KynMptUNCIZQp1ZafsfeY ugNyicVw9BJ8Nw7tmW2vyRvFFNUDeXpZfS6iD5vSNU3QnSg/Sr5qs3oHSQHltjw8 VsBwVwc2Co6wHwR2FrW2LQda3TNHke5XCWmVVvJi+clJvl4zQ8LWINO+hmzOXgPL O29hStrvkRhT5F5GBMnu9AIdFR8eccgv/BuLmQ3ASnoG7YRRiLSKkFFJuYzbKnFK VoJwaJBK5QAbjqi/wAWF3mCOgqvzrozuV7RrrJ9Ah/5J74VQoBdIuvPG7oYDXu8n bZBEIEhLrHvc6wUevXKR3K6xFGQxI+0+Nv5GmqjuehktHx/Cf3Td7c0hIPNw0sgN VSASIhG0//x35e7lhzroeLjSUgvQNfcYH6d7JKropvkNQOsxV42ISVMVQouKLMJ+ fPEwy1ZyoUrJ6XCrzozyePaL5K18BlL8OGGs5yo5UWxoBonLvh20cJjGAkAh/Er2 a1Dwijc2ulkO4WnJn3RpKaCuEYCC8lBwakqAwLdzC5nJVQD5ZaQPcK8P63Zd5DeM Kmkli3NEILi8JAaVHIoYB6fmd4VBH4sbGJbccISX65SyVr4HpnUbPcLgjBxlL0PG RV8MwZ5fGmxpbVrXBbK7sO/a951kib+GJiMU8wlAqs0+cDc5kse/YzOEl+lc8iG1 krw5V+wCqB/NR8e+nTGQ =lN0r -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
