You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Chris Ward (JIRA)" <ji...@apache.org> on 2007/08/20 20:19:31 UTC

[jira] Created: (OPENJPA-324) The MetaDataRepository class is not thread safe. Initialization under heavy load on a multi CPU/Core systems throws exceptions.

The MetaDataRepository class is not thread safe.  Initialization under heavy load on a multi CPU/Core systems throws exceptions.
--------------------------------------------------------------------------------------------------------------------------------

                 Key: OPENJPA-324
                 URL: https://issues.apache.org/jira/browse/OPENJPA-324
             Project: OpenJPA
          Issue Type: Bug
          Components: kernel
    Affects Versions: 0.9.7, 0.9.6
         Environment: I have reproduced the problem in Windows and in Solaris.  It only affects multi core/CPU systems.  I haven't reproduced the problem on single core systems.

I am using Spring 2.0.2 and OpenJPA 0.9.6 with an Oracle 10g database.

            Reporter: Chris Ward


OpenJPA's MetaDataRepository fails to load metadata for classess when multiple threads use the same EntityManagerFactory class to resolve the metadata.  The MetaDataRepository implementation is not thread safe.The problem only occurrs on multi core or multi processor machines that can concurrently try to initialize meta data for classes.

To reproduce the problem I have inserted a sleep statement within the code to help reproduce the problem consistently.  I have commented out the sleep statement in my deployed version of the class.

This bug is sort of related to issue 250.  I have cleaned up all of the synchronization in the class.  There should be less contention, however it could still be better if a ReentrantReadWriteLock was used.  I noticed that someone had posted a new MetaDataRepository with a ReentrantReadWriteLock, but too seems to have the same issues.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-324) The MetaDataRepository class is not thread safe. Initialization under heavy load on a multi CPU/Core systems throws exceptions.

Posted by "Chris Ward (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/OPENJPA-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Ward updated OPENJPA-324:
-------------------------------

    Attachment: MetaDataRepository.java

I have attached the source code with the corrected synchronization.

> The MetaDataRepository class is not thread safe.  Initialization under heavy load on a multi CPU/Core systems throws exceptions.
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-324
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-324
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 0.9.6, 0.9.7
>         Environment: I have reproduced the problem in Windows and in Solaris.  It only affects multi core/CPU systems.  I haven't reproduced the problem on single core systems.
> I am using Spring 2.0.2 and OpenJPA 0.9.6 with an Oracle 10g database.
>            Reporter: Chris Ward
>         Attachments: MetaDataRepository.java
>
>
> OpenJPA's MetaDataRepository fails to load metadata for classess when multiple threads use the same EntityManagerFactory class to resolve the metadata.  The MetaDataRepository implementation is not thread safe.The problem only occurrs on multi core or multi processor machines that can concurrently try to initialize meta data for classes.
> To reproduce the problem I have inserted a sleep statement within the code to help reproduce the problem consistently.  I have commented out the sleep statement in my deployed version of the class.
> This bug is sort of related to issue 250.  I have cleaned up all of the synchronization in the class.  There should be less contention, however it could still be better if a ReentrantReadWriteLock was used.  I noticed that someone had posted a new MetaDataRepository with a ReentrantReadWriteLock, but too seems to have the same issues.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-324) The MetaDataRepository class is not thread safe. Initialization under heavy load on a multi CPU/Core systems throws exceptions.

Posted by "Chris Ward (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OPENJPA-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521868 ] 

Chris Ward commented on OPENJPA-324:
------------------------------------

I have tried listing and not list the types in the persistence unit with the same result.  If you access the EM before doing any real work then it is not a problem, because you have a single thead that is triggering the load of data into the MetaDataRepository.  I am using OpenJPA within a web service and I can potentialy have several threads accessing an EMF to acquire an EM per thread at the same time and performing real work.  Since the metadata is lazy loaded into the MetaDataRepository you can have multiple threads triggering the load at the same time.  After looking at the code I was able to exaggerate the problem by adding a sleep call within the MetaDataRepository to consistently reproduce the problem.  I left that line commented out in the attached java file.  If you put the line in the same spot in the old code you should be able to reproduce the problem on a multi core machine.

The first thread to try to load the meta data always succeeds, and all other threads concruently trying to load the meta data always fail.  Once the meta data has been loaded, all new requests coming in succeed.  It is only a problem durring the load.

> The MetaDataRepository class is not thread safe.  Initialization under heavy load on a multi CPU/Core systems throws exceptions.
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-324
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-324
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 0.9.6, 0.9.7
>         Environment: I have reproduced the problem in Windows and in Solaris.  It only affects multi core/CPU systems.  I haven't reproduced the problem on single core systems.
> I am using Spring 2.0.2 and OpenJPA 0.9.6 with an Oracle 10g database.
>            Reporter: Chris Ward
>         Attachments: MetaDataRepository.java
>
>
> OpenJPA's MetaDataRepository fails to load metadata for classess when multiple threads use the same EntityManagerFactory class to resolve the metadata.  The MetaDataRepository implementation is not thread safe.The problem only occurrs on multi core or multi processor machines that can concurrently try to initialize meta data for classes.
> To reproduce the problem I have inserted a sleep statement within the code to help reproduce the problem consistently.  I have commented out the sleep statement in my deployed version of the class.
> This bug is sort of related to issue 250.  I have cleaned up all of the synchronization in the class.  There should be less contention, however it could still be better if a ReentrantReadWriteLock was used.  I noticed that someone had posted a new MetaDataRepository with a ReentrantReadWriteLock, but too seems to have the same issues.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OPENJPA-324) The MetaDataRepository class is not thread safe. Initialization under heavy load on a multi CPU/Core systems throws exceptions.

Posted by "Rick Curtis (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/OPENJPA-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Curtis closed OPENJPA-324.
-------------------------------

      Assignee: Rick Curtis
    Resolution: Won't Fix

We have done extensive performance/scalability work on the MetaDataRepsitory and this is no longer an issue. Please re-open if you disagree.

Thanks,
Rick

> The MetaDataRepository class is not thread safe.  Initialization under heavy load on a multi CPU/Core systems throws exceptions.
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-324
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-324
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 0.9.6, 0.9.7
>         Environment: I have reproduced the problem in Windows and in Solaris.  It only affects multi core/CPU systems.  I haven't reproduced the problem on single core systems.
> I am using Spring 2.0.2 and OpenJPA 0.9.6 with an Oracle 10g database.
>            Reporter: Chris Ward
>            Assignee: Rick Curtis
>         Attachments: MetaDataRepository.java
>
>
> OpenJPA's MetaDataRepository fails to load metadata for classess when multiple threads use the same EntityManagerFactory class to resolve the metadata.  The MetaDataRepository implementation is not thread safe.The problem only occurrs on multi core or multi processor machines that can concurrently try to initialize meta data for classes.
> To reproduce the problem I have inserted a sleep statement within the code to help reproduce the problem consistently.  I have commented out the sleep statement in my deployed version of the class.
> This bug is sort of related to issue 250.  I have cleaned up all of the synchronization in the class.  There should be less contention, however it could still be better if a ReentrantReadWriteLock was used.  I noticed that someone had posted a new MetaDataRepository with a ReentrantReadWriteLock, but too seems to have the same issues.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-324) The MetaDataRepository class is not thread safe. Initialization under heavy load on a multi CPU/Core systems throws exceptions.

Posted by "Chris Ward (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OPENJPA-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521185 ] 

Chris Ward commented on OPENJPA-324:
------------------------------------

I forgot to include the stack trace:

13:13:10,129 ERROR [QIPImpl] com.symcor.sis.tecp.qip.dao.exception.PersistenceException: Runtime Exception encountered while querying Header_Record.
com.symcor.sis.tecp.qip.dao.exception.PersistenceException: Runtime Exception encountered while querying Header_Record.
        at com.symcor.sis.tecp.qip.dao.HeaderDAOImpl.persistIfNotPresent(HeaderDAOImpl.java:45)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:281)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:187)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:154)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:107)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:176)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:210)
        at $Proxy422.persistIfNotPresent(Unknown Source)
        at com.symcor.sis.tecp.qip.delegate.QIPFileItemDelegateImpl.save(QIPFileItemDelegateImpl.java:58)
        at com.symcor.sis.tecp.qip.QIPImpl.save(QIPImpl.java:36)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:210)
        at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:132)
        at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:241)
        at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:74)
        at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:559)
        at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:518)
        at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:503)
        at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:400)
        at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:226)
        at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:375)
        at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:175)
        at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:134)
        at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:159)
        at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:49)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:615)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
        at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
        at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342)
        at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
        at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
        at java.lang.Thread.run(Thread.java:595)
Caused by: org.springframework.dao.InvalidDataAccessApiUsageException: The type "class com.symcor.sis.sisinternal.Header" has not been enhanced.; nest
ed exception is <4|true|0.9.6-incubating> org.apache.openjpa.persistence.ArgumentException: The type "class com.symcor.sis.sisinternal.Header" has not
 been enhanced.
        at org.springframework.orm.jpa.EntityManagerFactoryUtils.convertJpaAccessExceptionIfPossible(EntityManagerFactoryUtils.java:190)
        at org.springframework.orm.jpa.DefaultJpaDialect.translateExceptionIfPossible(DefaultJpaDialect.java:113)
        at org.springframework.dao.support.DataAccessUtils.translateIfNecessary(DataAccessUtils.java:212)
        at org.springframework.orm.jpa.JpaAccessor.translateIfNecessary(JpaAccessor.java:152)
        at org.springframework.orm.jpa.JpaTemplate.execute(JpaTemplate.java:196)
        at org.springframework.orm.jpa.JpaTemplate.executeFind(JpaTemplate.java:158)
        at org.springframework.orm.jpa.JpaTemplate.find(JpaTemplate.java:305)
        at com.symcor.sis.tecp.qip.dao.HeaderDAOImpl.persistIfNotPresent(HeaderDAOImpl.java:42)
        ... 51 more
Caused by: <4|true|0.9.6-incubating> org.apache.openjpa.persistence.ArgumentException: The type "class com.symcor.sis.sisinternal.Header" has not been
 enhanced.
        at org.apache.openjpa.meta.ClassMetaData.resolveMeta(ClassMetaData.java:1590)
        at org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1564)
        at org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataRepository.java:654)
        at org.apache.openjpa.meta.MetaDataRepository.resolveMeta(MetaDataRepository.java:554)
        at org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:479)
        at org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:283)
        at org.apache.openjpa.meta.MetaDataRepository.resolveMeta(MetaDataRepository.java:519)
        at org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:479)
        at org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:283)
        at org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:338)
        at org.apache.openjpa.kernel.QueryImpl.classForName(QueryImpl.java:1540)
        at org.apache.openjpa.kernel.ExpressionStoreQuery$1.classForName(ExpressionStoreQuery.java:104)
        at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:160)
        at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:131)
        at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:211)
        at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:181)
        at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:174)
        at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500(JPQLExpressionBuilder.java:61)
        at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:1657)
        at org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:52)
        at org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:145)
        at org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:642)
        at org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:623)
        at org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:589)
        at org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:651)
        at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1464)
        at org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:120)
        at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:202)
        at org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:251)
        at org.springframework.orm.jpa.JpaTemplate$9.doInJpa(JpaTemplate.java:313)
        at org.springframework.orm.jpa.JpaTemplate.execute(JpaTemplate.java:191)
        ... 54 more


> The MetaDataRepository class is not thread safe.  Initialization under heavy load on a multi CPU/Core systems throws exceptions.
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-324
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-324
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 0.9.6, 0.9.7
>         Environment: I have reproduced the problem in Windows and in Solaris.  It only affects multi core/CPU systems.  I haven't reproduced the problem on single core systems.
> I am using Spring 2.0.2 and OpenJPA 0.9.6 with an Oracle 10g database.
>            Reporter: Chris Ward
>         Attachments: MetaDataRepository.java
>
>
> OpenJPA's MetaDataRepository fails to load metadata for classess when multiple threads use the same EntityManagerFactory class to resolve the metadata.  The MetaDataRepository implementation is not thread safe.The problem only occurrs on multi core or multi processor machines that can concurrently try to initialize meta data for classes.
> To reproduce the problem I have inserted a sleep statement within the code to help reproduce the problem consistently.  I have commented out the sleep statement in my deployed version of the class.
> This bug is sort of related to issue 250.  I have cleaned up all of the synchronization in the class.  There should be less contention, however it could still be better if a ReentrantReadWriteLock was used.  I noticed that someone had posted a new MetaDataRepository with a ReentrantReadWriteLock, but too seems to have the same issues.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-324) The MetaDataRepository class is not thread safe. Initialization under heavy load on a multi CPU/Core systems throws exceptions.

Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OPENJPA-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521216 ] 

Patrick Linskey commented on OPENJPA-324:
-----------------------------------------

Does this happen if you list all of your persistent types in your persistence unit and obtain an EM before doing any "real" work in the system?

> The MetaDataRepository class is not thread safe.  Initialization under heavy load on a multi CPU/Core systems throws exceptions.
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-324
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-324
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 0.9.6, 0.9.7
>         Environment: I have reproduced the problem in Windows and in Solaris.  It only affects multi core/CPU systems.  I haven't reproduced the problem on single core systems.
> I am using Spring 2.0.2 and OpenJPA 0.9.6 with an Oracle 10g database.
>            Reporter: Chris Ward
>         Attachments: MetaDataRepository.java
>
>
> OpenJPA's MetaDataRepository fails to load metadata for classess when multiple threads use the same EntityManagerFactory class to resolve the metadata.  The MetaDataRepository implementation is not thread safe.The problem only occurrs on multi core or multi processor machines that can concurrently try to initialize meta data for classes.
> To reproduce the problem I have inserted a sleep statement within the code to help reproduce the problem consistently.  I have commented out the sleep statement in my deployed version of the class.
> This bug is sort of related to issue 250.  I have cleaned up all of the synchronization in the class.  There should be less contention, however it could still be better if a ReentrantReadWriteLock was used.  I noticed that someone had posted a new MetaDataRepository with a ReentrantReadWriteLock, but too seems to have the same issues.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.