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 or, alternatively, the class loader that loaded the thread class. > 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. > ********************************************************** > > 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
