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
>
>
>
>
>
>
