|Re: [jetty-users] java.lang.OutOfMemoryError: PermGen space|
Could the DriverManagerLeakPreventer help?https://github.com/eclipse/jetty.project/blob/master/jetty-util/src/main/java/org/eclipse/jetty/util/preventers/DriverManagerLeakPreventer.javaIt will pin the DriverManager at the server side classloader.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
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.
On 14-04-30 11:48 AM, Jan Bartel wrote:
> 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.
> 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
>> 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
>> by putting this into my jetty.xml file:
>> <Call name="addBean">
>> But it didn’t seem to make a difference.
>> Any ideas or pointers to appropriate documentation?
>> jetty-users mailing list
jetty-users mailing list
jetty-users mailing list
Back to the top