I think this (https://github.com/mjiderhamn/classloader-leak-prevention) is the most comprehensive (and application server independent) listener for preventing classloader memory leaks. I agree that not packaging the database driver with the web app is a good idea although the listener should clean up that particular leak.
The classloader-leak-prevention listener's author also has a good series discussing classloader leaks (why they happen and how to track them down) on his blog: http://java.jiderhamn.se/ On Wed, Apr 30, 2014 at 1:21 PM, Joakim Erdfelt <[email protected]> wrote: > Could the DriverManagerLeakPreventer help? > > https://github.com/eclipse/jetty.project/blob/master/jetty-util/src/main/java/org/eclipse/jetty/util/preventers/DriverManagerLeakPreventer.java > > It will pin the DriverManager at the server side classloader. > > > -- > Joakim Erdfelt <[email protected]> > webtide.com <http://www.webtide.com/> - intalio.com/jetty > Expert advice, services and support from from the Jetty & CometD experts > eclipse.org/jetty - cometd.org > > > On Wed, Apr 30, 2014 at 9:31 AM, Andrew Eidsness <[email protected]>wrote: > >> Jetty is deployed on my server and is running as a stand-alone daemon. >> I'm deploying the war by copying into the >> webapps folder. >> >> Following the class loader references I think the problem is that >> java.sql.DriverManager.registeredDrivers is keeping an >> instance of my org.postgresql.Driver from each deployed instance. The >> registeredDrivers member is an ArrayList of with >> 8 instances of java.sql.DriverInfo each holding an instance of >> org.postgresql.Driver. DriverManager was loaded by the >> system class loader but the postgres Driver was loaded by the webapp's >> loader. >> >> I think the fix is to stop deploying my postgres connector as part of the >> webapp. I don't have a real reason for >> deploying it that way, it was just for convenience when I was setting up >> the project. I'll copy it into my jetty >> deployment instead and see what happens. >> >> Thanks for your help. My main problem here is not being confident in how >> I've setup things. I've used Google to find >> documentation for small parts of various versions. However, I think I'm >> making progress now. >> >> -Andrew >> >> On 14-04-30 11:48 AM, Jan Bartel wrote: >> > Andrew, >> > >> > How are you running jetty? In a standalone distro, as the maven >> > plugin, or via embedded code? I take it that the webapp is being >> > unpacked to a tmp directory? >> > >> > It does sound as if the WebAppClassloader is being pinned. There >> > should be a way with the heap dump tool to follow back to the objects >> > that are keeping references to the WebAppClassLoaders, or follow the >> > link from the doc page to the blog entry about classloader pinning, >> > which describes how to use JVisualVM to hunt down the references. >> > >> > Jan >> > >> > >> > >> > On 1 May 2014 01:11, Andrew Eidsness <[email protected]> wrote: >> >> My jetty server (9.1.4.v20140401) eventually runs out of memory after >> I’ve >> >> deployed the same war (during development) to the webapps folder. After >> >> looking in the bugs database I think this might be happening because >> I’m >> >> deploying jars inside the war’s lib folder. >> >> >> >> The reason I think this is that looking at the heap dump (in MAT) I >> can see >> >> 8 copies of classes from those bundled jars. Each of the instances was >> >> loaded by a different instance of >> >> org.eclipse.jetty.webapp.WebAppClassLoader. >> >> >> >> My theory is that when the war is redeployed a new instance of >> >> WebAppClassLoader is created which then loads the new jar files. >> >> >> >> I think I’m doing something wrong, but haven’t been able to figure out >> what. >> >> I’m not sure how to get the old class loader’s to go away. >> >> >> >> I’ve tried using the leak preventer >> >> ( >> http://www.eclipse.org/jetty/documentation/current/preventing-memory-leaks.html >> ) >> >> by putting this into my jetty.xml file: >> >> >> >> <Call name="addBean"> >> >> <Arg> >> >> <New >> >> class="org.eclipse.jetty.util.preventers.AppContextLeakPreventer"/> >> >> </Arg> >> >> </Call> >> >> >> >> But it didn’t seem to make a difference. >> >> >> >> Any ideas or pointers to appropriate documentation? >> >> >> >> Thanks, >> >> -Andrew >> >> >> >> >> >> _______________________________________________ >> >> jetty-users mailing list >> >> [email protected] >> >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> >> > >> > >> > >> >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> > > > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users > >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
