You may be interested in adding one more tool for solving memory leaks into your toolbox: http://plumbr.eu . We have tried to explain the reasons behind class loader leaks in some of our blog posts: https://plumbr.eu/blog/what-is-a-permgen-leak, https://plumbr.eu/permgen to name a few...
Nikita Salnikov-Tarnovski @iNikem/@JavaPlumbr On 30 April 2014 21:14, Andrew Eidsness <[email protected]> wrote: > Moving the postgres driver out of the .war file seems to have fixed my > problem. I think that is a good change anyhow. > It was only really added to the .war because it was convenient at the time. > > I hadn't noticed the DriverManagerLeakPreventer when I first looked > through the list (probably because at that time I > didn't realize that it was the problem). I assume it would solve the > problem as well. > > Mattias' preventer looks interesting too, I've added it to my list of > things to try out. Thanks. > > -Andrew > > On 14-04-30 01:40 PM, Hal Deadman wrote: > > 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]<mailto: > [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] <mailto:[email protected]>> > > webtide.com <http://www.webtide.com/> - intalio.com/jetty < > http://intalio.com/jetty> > > Expert advice, services and support from from the Jetty & CometD > experts > > eclipse.org/jetty <http://eclipse.org/jetty/> - cometd.org < > http://cometd.org/> > > > > > > On Wed, Apr 30, 2014 at 9:31 AM, Andrew Eidsness > > <[email protected]<mailto: > [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]<mailto: > [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] <mailto:[email protected]> > > >> https://dev.eclipse.org/mailman/listinfo/jetty-users > > >> > > > > > > > > > > > > > _______________________________________________ > > jetty-users mailing list > > [email protected] <mailto:[email protected]> > > https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > > > > > _______________________________________________ > > jetty-users mailing list > > [email protected] <mailto:[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
