Hi Dirk, Thanks for the memory refresh... :-) The JIRA you pointed out only provides the deRegister() method. There were no changes in OpenJPA to call this directly. It was provided for embedders of OpenJPA to clean up after classloaders change. Are you suggesting that Felix should change to call this deRegister() method? Or, are you asking for OpenJPA to be smarter on when this deRegister processing could be done? I'm not sure the latter is possible... Since we don't know when a classloader change is warranted or not...
Just looking to understand what's being requested. Thanks. -- Kevin On Mon, Sep 30, 2013 at 2:00 AM, Rudolph, Dirk <dirk.rudo...@t-systems.com>wrote: > And me again... > > I found an nearly exactly identical discussion in the archives [1] and the > related ticket [2]. > > So it seems to be necessary to fix this issue by calling > PCRegistry.deRegister when persistence bundle state changes in OSGI > frameworks (specially we are using Apache Felix) > > [1] > > http://mail-archives.apache.org/mod_mbox/openjpa-dev/200707.mbox/%3cfbb27544-a571-4c30-af39-e0822f81d...@gmail.com%3E > > [2] > https://issues.apache.org/jira/browse/OPENJPA-285 > > -----Ursprüngliche Nachricht----- > Von: Rudolph, Dirk > Gesendet: Samstag, 28. September 2013 17:38 > An: users@openjpa.apache.org > Betreff: AW: ClassNotFoundExceptions for Entity classes after bundle > redeployment > > Hi, me again. > > I have made an Heap dump and it confirms my assumption that only > PCRegistry holds references to the entity classes. Each entity class occurs > three times after the following procedure: > > 1. Startup > 2. Invoke DB access > 3. Redeploy persistance bundle > 4. Invoke DB access > 5. Redeploy persistance bundle > 6. Invoke DB access > > All in all 27 entity classes are in the PCRegistry. What I'm doing wrong? > > Thanks agian, > Dirk > > -----Ursprüngliche Nachricht----- > Von: Rudolph, Dirk > Gesendet: Samstag, 28. September 2013 08:19 > An: users@openjpa.apache.org > Betreff: AW: ClassNotFoundExceptions for Entity classes after bundle > redeployment > > Hi Kevin, > > we are using OpenJPA 2.2.2 with container-managed persistence with Apache > Aries JPA container (1.1.0) and when the persistence bundle is redeployed > the container deregisters the EMFs as expected (I think). The enhancement > is done on build time and PCRegistry.register is called for each entity in > static initializer as expected. > > I think the problem is that Felix instantiates a new ClassLoader when a > bundle is redoplyed. All classes loaded with the new ClassLoader are not > equal to the classes loaded with the old ClassLoader. These new classes get > initialized and the static initializer puts them in the PCRegistry without > removing instances of the previous ClassLoader. I checked our codebase > whether any instance holds references to instances of our entities but > couldn't find any. I'm not sure why the classes in PCRegistry don't get > collected by the garbage collector when the bundle is stopped before > update. Am I responsible for closing EM during deactivation of my > persistence service or is this also done by the container when EMF is > deregistered? > > <?xml version="1.0" encoding="UTF-8"?> > <persistence > version="2.0" > xmlns="http://java.sun.com/xml/ns/persistence"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/persistence > http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd";> > > <persistence-unit name="myUserBundlePU" transaction-type="JTA"> > <description>Persistence Unit for user service. Uses container > managed transactions.</description> > > <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider> > > <jta-data-source> > osgi:service/javax.sql.DataSource/(datasource-mode=jta) > </jta-data-source> > <non-jta-data-source> > osgi:service/javax.sql.DataSource/(datasource-mode=non-jta) > </non-jta-data-source> > > <!-- Entity classes --> > <class>my.user.impl.entities.UserProfileEntity</class> > <class>my.user.impl.entities.NewsletterSubscriptionEntity</class> > <class>my.user.impl.entities.NewsletterStateEntity</class> > <class>my.user.impl.entities.ArticleEntity</class> > <class>my.user.impl.entities.ArticleUserInformationEntity</class> > <class>my.user.impl.entities.DistributionListEntity</class> > <class>my.user.impl.entities.DistributionListUserEntity</class> > <class>my.user.impl.entities.DistributionListFirmEntity</class> > <class>my.user.impl.entities.FirmEntity</class> > <exclude-unlisted-classes>true</exclude-unlisted-classes> > > <properties> > <property name="openjpa.Log" value="DefaultLevel=INFO, > Runtime=INFO, SQL=INFO, Tool=INFO" /> > </properties> > </persistence-unit> > </persistence> > > Thanks so far, > Dirk > > -----Ursprüngliche Nachricht----- > Von: Kevin Sutter [mailto:kwsut...@gmail.com] > Gesendet: Donnerstag, 26. September 2013 14:57 > An: users@openjpa.apache.org > Betreff: Re: ClassNotFoundExceptions for Entity classes after bundle > redeployment > > Hi Dirk, > Are you using container-managed persistence or application-managed > persistence? That is, who is controlling the lifecycle of your EMFs and > EMs? If the PCRegistry is continuing to grow and grow and grow, this > sounds like an EMF or EM leak where they are not getting properly closed. > > What version of OpenJPA is in use? In 2.2.0, OpenJPA put a feature in > place [1] that helps with resolving memory issues when failing to close > EMFs. > > Another thing to look at is how you are enhancing your Entities for > OpenJPA monitoring. Are you doing build-time enhancement or some type of > runtime enhancement? Posting your persistence.xml would also be good. > > -- Kevin > > [1] https://issues.apache.org/jira/browse/OPENJPA-2042 > > > On Thu, Sep 26, 2013 at 3:52 AM, Rudolph, Dirk > <dirk.rudo...@t-systems.com>wrote: > > > Hi all, > > > > > > > > we are using OpenJPA in our osgi environment (Apache Felix) and got > > some (non-deterministic ) ClassNotFoundExceptions caused by already > closed jars. > > This occurs only when the persistence bundle we are using is redeployed. > > > > > > > > We mentioned that the PCRegistry.register method is invoked when our > > Entity-classes get instantiated. This works as expected. The meta data > > map of the Registry is filled and successfully passed through the > > MetadataRepository. After a redeployment this happens again and again > > so the map of registered metas in the PCRegistry grows and grows and > > contains classes referencing already disposed classloaders. When the > > registered metadata get used this can cause ClassNotFoundExceptions > > when an outdated classloader is access. I assume that this happens > > non-deterministic because the order of the data to iterate over isn't > > predictable. Is this diagnostic right? > > > > > > > > Should PCRegistry.deRegister be called when a bundle is stopped before > > update? Can this be done by any configuration? > > > > > > > > Thank's so far, > > > > > > > > > > Dirk Rudolph > > > > > > > > > > T-Systems Multimedia Solutions GmbH > > Organisationseinheit CCS > > Dirk Rudolph > > Software-Entwicklung, OCJP > > > > Hausanschrift: Riesaer Straße 5, 01129 Dresden > > Postanschrift: Postfach 10 02 24, 01072 Dresden > > +49 351 2820-5363 (Tel) > > E-Mail: dirk.rudo...@t-systems.com > > <mailto:mdirk.rudo...@t-systems-mms.com > > > > > Internet: http://www.t-systems-mms.com <http://www.t-systems-mms.de/> > > > > T-Systems Multimedia Solutions GmbH > > > > Aufsichtsrat: Klaus Werner (Vorsitzender) > > Geschäftsführung: Peter Klingenburg, Dr. Jens Nebendahl > > Handelsregister: Amtsgericht Dresden HRB 11433 Sitz der Gesellschaft: > > Dresden > > Ust-IdNr.: DE 811 807 949 > > > > > > > > > > > > >
