Hi, The issue was identified, the blocking threads in getServiceReference() were caused by essential CPU overload on test system. Nothing to do with Aries at all. Sorry for noise.
Regards, Andrei. > -----Original Message----- > From: Andrei Shakirin [mailto:[email protected]] > Sent: Sonntag, 17. Dezember 2017 22:38 > To: [email protected] > Cc: [email protected] > Subject: Blocked threads by getServiceReference() for TransactionManager > > Hi, > > This question doesn't directly relate to Aries, but perhaps you have ideas > what > happens here on the base of your OSGi experience. > I use Aries together with Hybernate in Karaf container configured with Equinox > OSGi implementation. > > By load test I encounter a lot of threads in blocked status with following > stack > trace: > > ArticlePAAThread id=25831 state=RUNNABLE > at > org.eclipse.osgi.container.ModuleRevisions.getCurrentRevision(ModuleRevision > s.java:82) > at org.eclipse.osgi.container.Module.getCurrentRevision(Module.java:226) > at > org.eclipse.osgi.internal.loader.sources.PackageSource.getBundleLoader(Packa > geSource.java:190) > at > org.eclipse.osgi.internal.loader.sources.PackageSource.isServiceAssignableTo(P > ackageSource.java:125) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.isAssignableTo( > ServiceRegistrationImpl.java:655) > at > org.eclipse.osgi.internal.serviceregistry.ServiceReferenceImpl.isAssignableTo(S > erviceReferenceImpl.java:169) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.isAssignableTo(Service > Registry.java:1143) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getServiceReferences(S > erviceRegistry.java:318) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getServiceReference(Se > rviceRegistry.java:382) > at > org.eclipse.osgi.internal.framework.BundleContextImpl.getServiceReference(B > undleContextImpl.java:561) > at > org.hibernate.osgi.OsgiJtaPlatform.retrieveTransactionManager(OsgiJtaPlatfor > m.java:54) > at > org.hibernate.osgi.OsgiJtaPlatform.canRegisterSynchronization(OsgiJtaPlatform > .java:72) > at > org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl.attempt > ToRegisterJtaSync(TransactionCoordinatorImpl.java:247) > at > org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl.pulse(Tr > ansactionCoordinatorImpl.java:284) > at > org.hibernate.ejb.AbstractEntityManagerImpl.joinTransaction(AbstractEntityMa > nagerImpl.java:1212) > at > org.hibernate.ejb.AbstractEntityManagerImpl.postInit(AbstractEntityManagerI > mpl.java:178) > at org.hibernate.ejb.EntityManagerImpl.<init>(EntityManagerImpl.java:89) > at > org.hibernate.ejb.EntityManagerFactoryImpl.createEntityManager(EntityMana > gerFactoryImpl.java:193) > at sun.reflect.GeneratedMethodAccessor137.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI > mpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.aries.jpa.container.quiesce.impl.QuiesceEMFHandler.invoke(Quiesc > eEMFHandler.java:58) > at com.sun.proxy.$Proxy130.createEntityManager(Unknown Source) > at > org.apache.aries.jpa.container.context.transaction.impl.JTAPersistenceContext > Registry.getCurrentPersistenceContext(JTAPersistenceContextRegistry.java:152 > ) > at > org.apache.aries.jpa.container.context.transaction.impl.JTAEntityManagerHand > ler.getPersistenceContext(JTAEntityManagerHandler.java:111) > at > org.apache.aries.jpa.container.context.transaction.impl.JTAEntityManagerHand > ler.invoke(JTAEntityManagerHandler.java:182) > at com.sun.proxy.$Proxy131.unwrap(Unknown Source) > at org.testdao.AbstractDao.getSession(AbstractDao.java:29) > > The same happens by criteria search: > ArticlePAAThread id=2213 state=BLOCKED > - waiting to lock <0x0c2ec250> (a java.lang.Object) > owned by qtp537894753-24736 id=24736 > at > org.eclipse.osgi.container.ModuleRevisions.getCurrentRevision(ModuleRevision > s.java:82) > at org.eclipse.osgi.container.Module.getCurrentRevision(Module.java:226) > at > org.eclipse.osgi.internal.loader.sources.PackageSource.getBundleLoader(Packa > geSource.java:190) > at > org.eclipse.osgi.internal.loader.sources.PackageSource.isServiceAssignableTo(P > ackageSource.java:128) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.isAssignableTo( > ServiceRegistrationImpl.java:655) > at > org.eclipse.osgi.internal.serviceregistry.ServiceReferenceImpl.isAssignableTo(S > erviceReferenceImpl.java:169) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.isAssignableTo(Service > Registry.java:1143) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getServiceReferences(S > erviceRegistry.java:318) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getServiceReference(Se > rviceRegistry.java:382) > at > org.eclipse.osgi.internal.framework.BundleContextImpl.getServiceReference(B > undleContextImpl.java:561) > at > org.hibernate.osgi.OsgiJtaPlatform.retrieveTransactionManager(OsgiJtaPlatfor > m.java:54) > at > org.hibernate.engine.transaction.internal.jta.CMTTransaction.transactionMana > ger(CMTTransaction.java:57) > at > org.hibernate.engine.transaction.internal.jta.CMTTransaction.getTransactionM > anager(CMTTransaction.java:61) > at > org.hibernate.engine.transaction.internal.jta.CMTTransaction.isActive(CMTTra > nsaction.java:115) > at > org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl.isTransa > ctionInProgress(TransactionCoordinatorImpl.java:167) > at org.hibernate.internal.SessionImpl.afterOperation(SessionImpl.java:476) > at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1595) > at org.hibernate.internal.CriteriaImpl.list(CriteriaImpl.java:374) > at org. dao.impl.MyDaoImpl.getPrice (MyDaoImpl.java:40) > > Any idea why the > org.eclipse.osgi.container.ModuleRevisions.getCurrentRevision(ModuleRevision > s.java:82) blocks threads accessing DAO? > Are there any workarounds / things I can check? > > By googling I found a bug in eclipse forum, but regarding Logging: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=502360 > > Regards, > Andrei.
