geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: [jira] Commented: (GERONIMO-1062) OpenEJB client leaks memory on each JNDI lookup. Get OutOfMemoryException after a few thousand lookups
Date Fri, 21 Oct 2005 12:01:38 GMT
Hi David,
Thanks for the pointer. I'll take a look to understand why there
wasn't/isn't any caching going on.

--kevan

On 10/20/05, David Jencks <david_jencks@yahoo.com> wrote:
>
>
> On Oct 20, 2005, at 2:45 PM, Kevan Miller wrote:
>
> > Hi John,
> > You're correct.
> >
> > I have an OpenEJB patch which creates a ClassLoader per Proxy
> > creation in the OpenEJB client. This ClassLoader and the dynamically
> > generated classes can then be GCed when no longer in use. With this
> > patch, your test runs to completion (100,000 iterations) with no
> > noticeable growth in heap or permgen space.
> >
> > I'd like to investigate OpenEJB's class loading structure a bit
> > before I call this a fix. Also, this scenario (and other Geronimo
> > server scenarios) seems to be screaming for a little caching of the
> > proxy and associated dynamically generated classes...
>
>
> I spent a couple minutes looking at cglib source code and it looked to
> me as if they were making some effort to cache enhanced classes. I
> would start by trying to figure out why this isn't working for us.
> AbstractClassGenerator.create(Object key) line 199 looks like it's key.
>
> thanks
> david jencks
> >
> > --kevan
> >
> > On 10/17/05, John Sisson (JIRA) <dev@geronimo.apache.org> wrote: [
> > http://issues.apache.org/jira/browse/GERONIMO-1062?
> > page=comments#action_12332227 ]
> >>
> >> John Sisson commented on GERONIMO-1062:
> >> ---------------------------------------
> >>
> >> These proxy classes appear to be loaded by the AppClassLoader (system
> >> class loader).AFAIK, classes loaded by the system class loader
> >> never get unloaded.
> >>
> >> > OpenEJB client leaks memory on each JNDI lookup.Get
> >> OutOfMemoryException after a few thousand lookups
> >> >
> >> ----------------------------------------------------------------------
> >> ---------------------------------
> >> >
> >> >Key: GERONIMO-1062
> >> >URL: http://issues.apache.org/jira/browse/GERONIMO-1062
> >> >Project: Geronimo
> >> > Type: Bug
> >> > Components: OpenEJB
> >> > Versions: 1.0-M5, 1.0-M4
> >> >Environment: Windows XP
> >> > j2sdk1.4.2_08
> >> > Reporter: John Sisson
> >> > Priority: Critical
> >> >Fix For: 1.0
> >> >Attachments: AllObjects.zip, apps.zip
> >> >
> >> > I have a standalone java application that uses OpenEJB's JNDI
> >> implementation (org.openejb.client.RemoteInitialContextFactory ).It
> >> appears that each JNDI lookup of an EJB is leaking memory and it
> >> looks like it is related to cglib.
> >> > I have attached to this JIRA a simple EJB and standalone java
> >> client application that can be used to reproduce the problem.
> >> > Extract the zip file to the geronimo\sandbox directory
> >> > cd sandbox\echoTest
> >> > maven -o
> >> > deploy the echoTest.ear file in the sandbox\echoTest\target
> >> directory
> >> > cd sandbox\echoTestStandaloneClient
> >> > maven -o
> >> > cd target
> >> > java -jar echoTestStandaloneClient-0.1-SNAPSHOT.jar
> >> > The console will be updated with the number of lookups
> >> performed.E.G here are a few examples with different JVM settings:
> >> >
> >> C:\OpenSourceJava\geronimo\trunk\sandbox\echoTestStandaloneClient>set
> >> JAVA_HOME=C:\Program Files\Java\j2sdk1.4.2_08
> >> >
> >> C:
> >> \OpenSourceJava\geronimo\trunk\sandbox\echoTestStandaloneClient>"%JAVA
> >> _HOME%"\bin\java.exe -jar target\echoTestStandaloneClient-0.
> >> > 1-SNAPSHOT.jar
> >> > After 0 lookups: delta: 1,911,024, free: 1,911,024, used: 120,592,
> >> total: 2,031,616, max: 66,650,112
> >> > After 1000 lookups: delta: 417,040, free: 2,328,064, used:
> >> 2,603,520, total: 4,931,584, max: 66,650,112
> >> > After 2000 lookups: delta: 1,765,304, free: 4,093,368, used:
> >> 5,151,304, total: 9,244,672, max: 66,650,112
> >> > After 3000 lookups: delta: 1,759,288, free: 5,852,656, used:
> >> 7,303,696, total: 13,156,352, max: 66,650,112
> >> > After 4000 lookups: delta: 2,182,664, free: 8,035,320, used:
> >> 10,081,288, total: 18,116,608, max: 66,650,112
> >> > After 5000 lookups: delta: 1,579,184, free: 9,614,504, used:
> >> 11,574,104, total: 21,188,608, max: 66,650,112
> >> >Lookups performed: 5432
> >> > Exception in thread "main"
> >> net.sf.cglib.core.CodeGenerationException:
> >> java.lang.reflect.InvocationTargetExce
> >> > ption-->null
> >> > at net.sf.cglib.core.AbstractClassGenerator.create
> >> (AbstractClassGenerator.java:237)
> >> > at
> >> net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
> >> > at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:304)
> >> > at org.openejb.client.CgLibProxyFactory.newProxyInstance
> >> (CgLibProxyFactory.java:92)
> >> > at
> >> org.openejb.client.CgLibProxyFactory.newProxyInstance(CgLibProxyFactor
> >> y.java:81)
> >> > at
> >> org.openejb.client.ProxyManager.newProxyInstance(ProxyManager.java:
> >> 90)
> >> > at
> >> org.openejb.client.EJBHomeHandler.createEJBHomeProxy(EJBHomeHandler.ja
> >> va:106)
> >> > at
> >> org.openejb.client.JNDIContext.createEJBHomeProxy(JNDIContext.java:
> >> 212)
> >> > at org.openejb.client.JNDIContext.lookup
> >> (JNDIContext.java:245)
> >> > at
> >> javax.naming.InitialContext.lookup(InitialContext.java:347)
> >> > at
> >> org.acme.EchoTestStandaloneClient.testLookup(EchoTestStandaloneClient.
> >> java:87)
> >> > at org.acme.EchoTestStandaloneClient.main
> >> (EchoTestStandaloneClient.java:76)
> >> > Caused by: java.lang.reflect.InvocationTargetException
> >> > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown
> >> Source)
> >> > at sun.reflect.DelegatingMethodAccessorImpl.invoke
> >> (DelegatingMethodAccessorImpl.java:25)
> >> > at java.lang.reflect.Method.invoke(Method.java:324)
> >> > at
> >> net.sf.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:384)
> >> > at net.sf.cglib.core.AbstractClassGenerator.create
> >> (AbstractClassGenerator.java:219)
> >> > ... 11 more
> >> > Caused by: java.lang.OutOfMemoryError
> >> > If I try this on JDK 1.5.0_05, it is worse as the JVM becomes
> >> unresponsive and uses a lot of CPU and I have to kill the JVM:
> >> >
> >> C:
> >> \OpenSourceJava\geronimo\trunk\sandbox\echoTestStandaloneClient>java
> >> -jar target\echoTestStandaloneClient-0.1-SNAPSHOT.jar
> >> > After 0 lookups: delta: 1,863,336, free: 1,863,336, used: 168,280,
> >> total: 2,031,616, max: 66,650,112
> >> > After 1000 lookups: delta: 482,408, free: 2,345,744, used:
> >> 2,684,144, total: 5,029,888, max: 66,650,112
> >> > After 2000 lookups: delta: 1,865,064, free: 4,210,808, used:
> >> 5,267,336, total: 9,478,144, max: 66,650,112
> >> > After 3000 lookups: delta: 2,116,488, free: 6,327,296, used:
> >> 7,967,744, total: 14,295,040, max: 66,650,112
> >> > After 4000 lookups: delta: 2,007,008, free: 8,334,304, used:
> >> 10,499,104, total: 18,833,408, max: 66,650,112
> >> > After 5000 lookups: delta: 2,094,096, free: 10,428,400, used:
> >> 13,164,560, total: 23,592,960, max: 66,650,112
> >> >Lookups performed: 5099
> >>
> >> --
> >> This message is automatically generated by JIRA.
> >> -
> >> If you think it was sent incorrectly contact one of the
> >> administrators:
> >> http://issues.apache.org/jira/secure/Administrators.jspa
> >> -
> >> For more information on JIRA, see:
> >> http://www.atlassian.com/software/jira
> >>
> >
>
>

Mime
View raw message