Hi, My guess would be that this occurs when we create dynamic proxy objects for interfaces and isn't related to the load-time weaving at all (although the code was added at the same time). We end up with one classloader per set of interfaces we get asked to proxy, and we only cache the 64 (I think) most recently used classloaders for reuse. This does lead to quite a lot of classloaders, which has probably caused the increase in permgen usage. I can take a look at the code to try and make it a bit less classloader happy, but I also think this is yet another issue with Sun's use of PermGen!
Increasing PermGen should avoid any problems, I/We can try to improve the caching/reuse of classloaders to reduce the permgen load as well if you like. Regards, Tim ---------------------------------------- > Subject: Re: Another possible proxy problem > From: [email protected] > Date: Sun, 29 May 2011 12:23:52 -0700 > To: [email protected] > > I get this permgen space error even if I turn off the java agent but not if I > change -XX:MaxPermSize=128m to -XX:MaxPermSize=1024m so it probably isn't an > infinite loop. Is it possible that the load time weaving uses a really lot > more permgen space and that we need to e.g. double or quadruple the allotment? > > > thanks > david jencks > > > On May 29, 2011, at 12:43 AM, Timothy Ward wrote: > > > > > Hi David, > > > > The latest versions of the Aries JPA container (in trunk) now support > > load-time weaving of entity classes using weaving hooks (on 4.3 compliant > > frameworks). The itests for this function should also be running the proxy > > bundles, so I would expect that to be a reasonably good test of JPA + Proxy > > weaving. I'm afraid that I don't know any way of hooking in the existing > > Java Agent, though it might be possible by mocking up a > > java.lang.instrument.Instrumentation object and passing it to the premain > > of the agent in code. It would be quite a hairy code path to mock up though! > > > > Regards, > > > > Tim > > > >> From: [email protected] > >> Subject: Another possible proxy problem > >> Date: Sat, 28 May 2011 13:38:15 -0700 > >> To: [email protected] > >> > >> I think I've supplied enough SerialVersionUIDs so geronimo isn't running > >> into the ARIEA-665 problem. Now I get > >> > >> Caused by: java.lang.OutOfMemoryError: PermGen space > >> at java.lang.ClassLoader.defineClass1(Native Method) > >> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) > >> at java.lang.ClassLoader.defineClass(ClassLoader.java:616) > >> at > >> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:188) > >> at > >> org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:601) > >> at > >> org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:567) > >> at > >> org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:490) > >> at > >> org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:478) > >> at > >> org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:458) > >> at > >> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) > >> at > >> org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:400) > >> at > >> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:476) > >> at > >> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429) > >> at > >> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417) > >> at > >> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) > >> at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > >> at > >> org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:133) > >> at > >> org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:157) > >> at > >> org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:66) > >> at > >> javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:152) > >> at > >> javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:72) > >> at > >> org.apache.juddi.config.PersistenceManager.initializeEntityManagerFactory(PersistenceManager.java:57) > >> at org.apache.juddi.config.AppConfig.loadConfiguration(AppConfig.java:95) > >> at org.apache.juddi.config.AppConfig.(AppConfig.java:63) > >> at org.apache.juddi.config.AppConfig.getInstance(AppConfig.java:184) > >> at org.apache.juddi.config.AppConfig.getConfiguration(AppConfig.java:206) > >> at org.apache.juddi.Registry.start(Registry.java:57) > >> at org.apache.juddi.servlets.RegistryServlet.init(RegistryServlet.java:46) > >> at > >> org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1133) > >> at > >> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1087) > >> at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:996) > >> at > >> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4741) > >> > >> trying to start a pre-deployed ee app that uses openjpa persistence (not > >> through aries). I wonder if the proxy code is getting into some kind of > >> loop with the openjpa enhancement code? Has anyone tested the proxy code > >> in this kind of situation? > >> > >> Is there some new way to install the openjpa enhancement using the > >> framework weaving hooks that might sidestep this problem or avoid the need > >> for a javaagent (which the problem above is using)? > >> > >> thanks > >> david jencks > >> > > >
