Maybe this helps? (post from andreou)
I resolved this.
I used the "-clent" switch too (I read somewhere that -server does not
collect from the PermGen, or something along the lines). But the real
problem was having my jdbc driver inside the war file. I placed that in
<domainDir>/lib/ext and the leak was gone. (previously, the instance of the
driver that existed in java.sql.DriverManager was created by the web app
classloader, thus that classloader was referenced from the classloader that
loaded DriverManager itself, preventing collection). [Message sent by forum
member 'andreou' (andreou)]
http://forums.java.net/jive/thread.jspa?messageID=281359
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net
wim
-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly_at_gmail.com]
Sent: dinsdag 17 juni 2008 7:30
To: users_at_glassfish.dev.java.net
Subject: Re: RE: Trying to understand why toplink creates so many persistent
objects
Are you sure you've not got some of your own classes retaining references
and therefore preventing GC from cleaning up the classes.
One issue I see is that each client gets their own set of JPA instances...
if you accidentally store one of these JPA instances in, for example a Http
Session that's saved on the server, then each web client could keep all it's
accessed JPA instances in memory until the session expires
On Tue, Jun 17, 2008 at 12:41 AM, Wim V <wim_at_pizzastop.be> wrote:
By the way, that's 180.000 instances, 13MB.
Didn't seem like an incredible number to me.
Unless they're really "leaking", i.e. not being garbage collected.
Now THAT would surprise me.
But if it's the case, I'll look into it.
Cheers,
Wim
-----Original Message-----
From: Wim V [mailto:wim_at_pizzastop.be]
Sent: dinsdag 17 juni 2008 1:29
To: users_at_glassfish.dev.java.net
Subject: RE: RE: Trying to understand why toplink creates so many persistent
objects
Ouch. I'm sorry.
Are you saying these are not being collected??
Wim
-----Original Message-----
From: glassfish_at_javadesktop.org [mailto:glassfish_at_javadesktop.org]
Sent: dinsdag 17 juni 2008 1:20
To: users_at_glassfish.dev.java.net
Subject: Re: RE: Trying to understand why toplink creates so many persistent
objects
Hi Wim,
Thanks for following up. Are you saying that using lazy loading comes along
with the minor disadvantage of memory leaks?
Unfortunately, I need to used lazy loading, and I cannot live with such a
memory leak.
The number of instances and size of my cached application objects (e.g.
DbItem) is fine. My issue seems to be with toplink internal objects like
these:
4: 179672 12936384
oracle.toplink.essentials.internal.identitymaps.HardCacheWeakIdentityMap$Ref
erenceCacheKey
9: 179763 5752416
oracle.toplink.essentials.internal.helper.ConcurrencyManager
13 million instances?
I am not sure how to explain why so many of these are created and referenced
for a long time (in perm gen state). It does not look like it is related to
how many of my application objects are created.
[Message sent by forum member 'jbelis' (jbelis)]
http://forums.java.net/jive/thread.jspa?messageID=280589
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net