Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] java.lang.OutOfMemoryError: PermGen space
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 <joakim@xxxxxxxxxxx> wrote:
Could the DriverManagerLeakPreventer help?

It will pin the DriverManager at the server side classloader.


--
Joakim Erdfelt <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts


On Wed, Apr 30, 2014 at 9:31 AM, Andrew Eidsness <eclipse@xxxxxxxxxx> 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 <eclipse@xxxxxxxxxx> 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
>> jetty-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>
>
>

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users


Back to the top