[JBoss JIRA] (DROOLS-618) Thread deadlock on org.drools.util.CompositeClassLoader
by Shashank Agarwal (JIRA)
[ https://issues.jboss.org/browse/DROOLS-618?page=com.atlassian.jira.plugin... ]
Shashank Agarwal updated DROOLS-618:
------------------------------------
Attachment: http-54350-Processor15.txt
http-54350-Processor18.txt
http-54350-Processor20.txt
> Thread deadlock on org.drools.util.CompositeClassLoader
> -------------------------------------------------------
>
> Key: DROOLS-618
> URL: https://issues.jboss.org/browse/DROOLS-618
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.6.0.Final
> Environment: drools expert
> Reporter: Shashank Agarwal
> Assignee: Mark Proctor
> Attachments: http-54350-Processor15.txt, http-54350-Processor18.txt, http-54350-Processor20.txt
>
>
> Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0
> Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly.
> Name: http-54350-Processor15
> State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18
> Name: http-54350-Processor18
> State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15
> Name: http-54350-Processor20
> State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15
> Regarding out environment details:
> # We have windows box on which application runs.
> # The rules used are kept in .drl and .xls formats
> # Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession();
> # Setup a few session globals as well.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (DROOLS-618) Thread deadlock on org.drools.util.CompositeClassLoader
by Shashank Agarwal (JIRA)
Shashank Agarwal created DROOLS-618:
---------------------------------------
Summary: Thread deadlock on org.drools.util.CompositeClassLoader
Key: DROOLS-618
URL: https://issues.jboss.org/browse/DROOLS-618
Project: Drools
Issue Type: Bug
Affects Versions: 5.6.0.Final
Environment: drools expert
Reporter: Shashank Agarwal
Assignee: Mark Proctor
Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0
Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly.
Name: http-54350-Processor15
State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18
Name: http-54350-Processor18
State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15
Name: http-54350-Processor20
State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15
Regarding out environment details:
# We have windows box on which application runs.
# The rules used are kept in .drl and .xls formats
# Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession();
# Setup a few session globals as well.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing
by Dirk Franssen (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Dirk Franssen commented on WFLY-2387:
-------------------------------------
Just for info: injection in an entity listener on Glassfish 4.1 doesn't work either. (@Inject seems to be ignored and the field stays null, resulting in nullpointer exceptions)
Currently I also use the BeanManager workaround on Wildfly 8.1.0.Final. This BeanManager can be injected though, so no need for a jndi lookup.
{code:title=MyEntityListener.java|borderStyle=solid}
...
@Inject
BeanManager beanManager; //Workaround WFLY-2387
...
protected String getPrincipalName() {
//Workaround WFLY-2387
Set beans = beanManager.getBeans(Principal.class);
Bean bean = (Bean) beans.iterator().next();
CreationalContext ctx = beanManager.createCreationalContext(bean);
Principal principal = (Principal) beanManager.getReference(bean, Principal.class, ctx);
return principal.getName();
}
{code}
> CDI injection in entity listeners failing
> -----------------------------------------
>
> Key: WFLY-2387
> URL: https://issues.jboss.org/browse/WFLY-2387
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Scott Marlow
> Fix For: 9.0.0.Beta1
>
> Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> at org.jboss.weld.Container.instance(Container.java:65)
> at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> ... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (WFCORE-135) Eliminate customized usage of RuntimePermission
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-135?page=com.atlassian.jira.plugin... ]
David Lloyd updated WFCORE-135:
-------------------------------
Description:
The JDK defines the entire domain of valid RuntimePermission names.
Here's a listing:
{noformat}
org.jboss.as.controller.AccessAuditContext#GET_ACCESS_AUDIT_CONTEXT
org.jboss.as.controller.ModelController#ACCESS_PERMISSION
org.jboss.as.controller.access.Caller#CREATE_CALLER_PERMISSION
org.jboss.as.controller.access.Caller#GET_SUBJECT_PERMISSION
org.jboss.as.controller.registry.ImmutableManagementResourceRegistration#ACCESS_PERMISSION
org.jboss.as.server.CurrentServiceContainer#LOOKUP_CURRENT_SERVICE_CONTAINER
org.jboss.as.server.CurrentServiceContainer#SET_CURRENT_SERVICE_CONTAINER
org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex#DEPLOYMENT_REFLECTION_INDEX_PERMISSION
org.jboss.as.server.deployment.service.SecuredServiceRegistry#PERMISSION
{noformat}
was:
The JDK defines the entire domain of valid RuntimePermission names.
Here's a listing:
{noformat}
org.jboss.as.naming.NamingContext#SET_ACTIVE_NAMING_STORE
org.jboss.as.security.remoting.RemotingContext#SET_CONNECTION_PERMISSION
org.jboss.as.security.remoting.RemotingContext#CLEAR_CONNECTION_PERMISSION
org.jboss.as.security.remoting.RemotingContext#GET_CONNECTION_PERMISSION
org.jboss.as.security.remoting.RemotingContext#IS_SET_PERMISSION
{noformat}
> Eliminate customized usage of RuntimePermission
> -----------------------------------------------
>
> Key: WFCORE-135
> URL: https://issues.jboss.org/browse/WFCORE-135
> Project: WildFly Core
> Issue Type: Task
> Components: Server
> Reporter: David Lloyd
> Assignee: Eduardo Martins
> Fix For: 1.0.0.CR1
>
>
> The JDK defines the entire domain of valid RuntimePermission names.
> Here's a listing:
> {noformat}
> org.jboss.as.controller.AccessAuditContext#GET_ACCESS_AUDIT_CONTEXT
> org.jboss.as.controller.ModelController#ACCESS_PERMISSION
> org.jboss.as.controller.access.Caller#CREATE_CALLER_PERMISSION
> org.jboss.as.controller.access.Caller#GET_SUBJECT_PERMISSION
> org.jboss.as.controller.registry.ImmutableManagementResourceRegistration#ACCESS_PERMISSION
> org.jboss.as.server.CurrentServiceContainer#LOOKUP_CURRENT_SERVICE_CONTAINER
> org.jboss.as.server.CurrentServiceContainer#SET_CURRENT_SERVICE_CONTAINER
> org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex#DEPLOYMENT_REFLECTION_INDEX_PERMISSION
> org.jboss.as.server.deployment.service.SecuredServiceRegistry#PERMISSION
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (WFCORE-135) Eliminate customized usage of RuntimePermission
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-135?page=com.atlassian.jira.plugin... ]
David Lloyd moved WFLY-3917 to WFCORE-135:
------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-135 (was: WFLY-3917)
Component/s: Server
(was: Naming)
(was: Security)
Fix Version/s: 1.0.0.CR1
(was: 9.0.0.CR1)
> Eliminate customized usage of RuntimePermission
> -----------------------------------------------
>
> Key: WFCORE-135
> URL: https://issues.jboss.org/browse/WFCORE-135
> Project: WildFly Core
> Issue Type: Task
> Components: Server
> Reporter: David Lloyd
> Assignee: Eduardo Martins
> Fix For: 1.0.0.CR1
>
>
> The JDK defines the entire domain of valid RuntimePermission names.
> Here's a listing:
> {noformat}
> org.jboss.as.naming.NamingContext#SET_ACTIVE_NAMING_STORE
> org.jboss.as.security.remoting.RemotingContext#SET_CONNECTION_PERMISSION
> org.jboss.as.security.remoting.RemotingContext#CLEAR_CONNECTION_PERMISSION
> org.jboss.as.security.remoting.RemotingContext#GET_CONNECTION_PERMISSION
> org.jboss.as.security.remoting.RemotingContext#IS_SET_PERMISSION
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (WFLY-3917) Eliminate customized usage of RuntimePermission
by David Lloyd (JIRA)
David Lloyd created WFLY-3917:
---------------------------------
Summary: Eliminate customized usage of RuntimePermission
Key: WFLY-3917
URL: https://issues.jboss.org/browse/WFLY-3917
Project: WildFly
Issue Type: Task
Components: Naming, Security
Reporter: David Lloyd
Assignee: Eduardo Martins
Fix For: 9.0.0.CR1
The JDK defines the entire domain of valid RuntimePermission names.
Here's a listing:
{noformat}
org.jboss.as.naming.NamingContext#SET_ACTIVE_NAMING_STORE
org.jboss.as.security.remoting.RemotingContext#SET_CONNECTION_PERMISSION
org.jboss.as.security.remoting.RemotingContext#CLEAR_CONNECTION_PERMISSION
org.jboss.as.security.remoting.RemotingContext#GET_CONNECTION_PERMISSION
org.jboss.as.security.remoting.RemotingContext#IS_SET_PERMISSION
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (WFLY-3916) Eliminate customized usage of RuntimePermission
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3916?page=com.atlassian.jira.plugin.... ]
David Lloyd updated WFLY-3916:
------------------------------
Component/s: Security
> Eliminate customized usage of RuntimePermission
> -----------------------------------------------
>
> Key: WFLY-3916
> URL: https://issues.jboss.org/browse/WFLY-3916
> Project: WildFly
> Issue Type: Task
> Components: Naming, Security
> Reporter: David Lloyd
> Assignee: Eduardo Martins
> Fix For: 9.0.0.CR1
>
>
> The JDK defines the entire domain of valid RuntimePermission names.
> Here's a listing:
> {noformat}
> org.jboss.as.naming.NamingContext#SET_ACTIVE_NAMING_STORE
> org.jboss.as.security.remoting.RemotingContext#SET_CONNECTION_PERMISSION
> org.jboss.as.security.remoting.RemotingContext#CLEAR_CONNECTION_PERMISSION
> org.jboss.as.security.remoting.RemotingContext#GET_CONNECTION_PERMISSION
> org.jboss.as.security.remoting.RemotingContext#IS_SET_PERMISSION
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (WFLY-3916) Eliminate customized usage of RuntimePermission
by David Lloyd (JIRA)
David Lloyd created WFLY-3916:
---------------------------------
Summary: Eliminate customized usage of RuntimePermission
Key: WFLY-3916
URL: https://issues.jboss.org/browse/WFLY-3916
Project: WildFly
Issue Type: Task
Components: Naming
Reporter: David Lloyd
Assignee: Eduardo Martins
Fix For: 9.0.0.CR1
The JDK defines the entire domain of valid RuntimePermission names.
Here's a listing:
{noformat}
org.jboss.as.naming.NamingContext#SET_ACTIVE_NAMING_STORE
org.jboss.as.security.remoting.RemotingContext#SET_CONNECTION_PERMISSION
org.jboss.as.security.remoting.RemotingContext#CLEAR_CONNECTION_PERMISSION
org.jboss.as.security.remoting.RemotingContext#GET_CONNECTION_PERMISSION
org.jboss.as.security.remoting.RemotingContext#IS_SET_PERMISSION
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months