[JBoss JIRA] (WFLY-5213) Injecting external context or it's destinations in MDB fails
by Ondřej Kalman (JIRA)
Ondřej Kalman created WFLY-5213:
-----------------------------------
Summary: Injecting external context or it's destinations in MDB fails
Key: WFLY-5213
URL: https://issues.jboss.org/browse/WFLY-5213
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 10.0.0.Beta2
Reporter: Ondřej Kalman
Assignee: Jeff Mesnil
When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (DROOLS-766) RuleNetworkEvaluator infinite loop when doUpdatesReorderLeftMemory is called
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-766?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-766.
--------------------------------
Fix Version/s: 6.3.0.CR2
Resolution: Cannot Reproduce Bug
I ran the provided reproducer against master (drools 6.3.0.CR2) more than once and it always terminated correctly without falling in an endless loop. I honestly don't know which commit fixed this issue (if any) but please give a try to latest release and tell me if it works also for you.
> RuleNetworkEvaluator infinite loop when doUpdatesReorderLeftMemory is called
> ----------------------------------------------------------------------------
>
> Key: DROOLS-766
> URL: https://issues.jboss.org/browse/DROOLS-766
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
> Fix For: 6.3.0.CR2
>
> Attachments: infiniteLoopReproducer.jar, infiniteLoopReproducer_src.jar
>
>
> We are migrating our system to use drools 6.2.0.Final from 6.0.1.Final and one of our testcase which actually simulate several complex scenario is making drools (6.2.0.Final) going into an endless loop, while the same works fine in 6.0.1.Final.
> I took a thread dump and it seems stuck:
> {code}
> at org.drools.core.phreak.RuleNetworkEvaluator.doUpdatesReorderLeftMemory(RuleNetworkEvaluator.java:795)
> {code}
> While debugging the source code this is what i got:
> # LeftTupleMemory ltm = bm.getLeftTupleMemory();
> ** LeftTupleMemory is a LeftTupleList
> # leftTuple.getStagedNext();
> ** Always return the same object instance(leftTuple is a JoinNodeLeftTuple type), hence the loop never ends.
> Unfortunately i cannot provide the DRL files + domain classes involve and don't know if it would be even possible for me right now to recreate the same testcase without leaking internal information from the company i work for.
> ThreadDump
> {code}
> "Attach Listener" daemon prio=10 tid=0x00007fdb74001000 nid=0x88c waiting on condition [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "drools-worker-2" daemon prio=10 tid=0x00007fdb54003000 nid=0x803 waiting on condition [0x00007fdb9b7cc000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0000000783f213f0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> "pool-3-thread-1" prio=10 tid=0x00007fdba46de000 nid=0x764 waiting on condition [0x00007fdb9bbd6000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0000000783eba160> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> "Service Thread" daemon prio=10 tid=0x00007fdba40ad800 nid=0x754 runnable [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" daemon prio=10 tid=0x00007fdba40ab000 nid=0x753 waiting on condition [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" daemon prio=10 tid=0x00007fdba40a8000 nid=0x752 waiting on condition [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "JDWP Command Reader" daemon prio=10 tid=0x00007fdb68001000 nid=0x74e runnable [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "JDWP Event Helper Thread" daemon prio=10 tid=0x00007fdba40a6000 nid=0x74d runnable [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "JDWP Transport Listener: dt_socket" daemon prio=10 tid=0x00007fdba40a2800 nid=0x74c runnable [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" daemon prio=10 tid=0x00007fdba4094800 nid=0x74b runnable [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "Finalizer" daemon prio=10 tid=0x00007fdba4074800 nid=0x74a in Object.wait() [0x00007fdba0cfb000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000007838824e0> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
> - locked <0x00000007838824e0> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
> "Reference Handler" daemon prio=10 tid=0x00007fdba4072800 nid=0x749 in Object.wait() [0x00007fdba0dfc000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000007838820a0> (a java.lang.ref.Reference$Lock)
> at java.lang.Object.wait(Object.java:503)
> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
> - locked <0x00000007838820a0> (a java.lang.ref.Reference$Lock)
> "main" prio=10 tid=0x00007fdba400e800 nid=0x743 runnable [0x00007fdbad9a8000]
> java.lang.Thread.State: RUNNABLE
> at org.drools.core.phreak.RuleNetworkEvaluator.doUpdatesReorderLeftMemory(RuleNetworkEvaluator.java:795)
> at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:38)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:235)
> - locked <0x0000000783f2da90> (a org.drools.core.phreak.RuleExecutor)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:106)
> - locked <0x0000000783f2da90> (a org.drools.core.phreak.RuleExecutor)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1016)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1302)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1289)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1262)
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109)
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:34)
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:155)
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:76)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:723)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:697)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5212) IllegalStateException: no transaction associated with thread after undeploy
by Michal Vinkler (JIRA)
Michal Vinkler created WFLY-5212:
------------------------------------
Summary: IllegalStateException: no transaction associated with thread after undeploy
Key: WFLY-5212
URL: https://issues.jboss.org/browse/WFLY-5212
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Michal Vinkler
Assignee: Paul Ferraro
Priority: Minor
Intermittent failure, so far seen in only this scenario:
ejb-ejbservlet-undeploy-dist-sync
Setup: 4 node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application.
Right after undeploying the application servers perf19,20,21 logged this error approx. 50 times:
{code}
[JBossINF] [0m[31m18:37:43,800 ERROR [io.undertow.request] (default task-111) UT005023: Exception handling request to /clusterbench/ejbservlet: java.lang.IllegalStateException: no transaction associated with thread
[JBossINF] at org.infinispan.transaction.tm.DummyBaseTransactionManager.rollback(DummyBaseTransactionManager.java:94)
[JBossINF] at org.wildfly.clustering.ee.infinispan.ActiveTransactionBatch.discard(ActiveTransactionBatch.java:57)
[JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:131)
[JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:725)
[JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:367)
[JBossINF] at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
[JBossINF] at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:231)
[JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
[JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:281)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
[JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
[JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[JBossINF] at java.lang.Thread.run(Thread.java:745)
{code}
Server log:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5197) Intermittent javax.ejb.EJBException: Do not call non-public methods on EJB's
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5197?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-5197:
-------------------------------
Fix Version/s: 10.0.0.CR1
> Intermittent javax.ejb.EJBException: Do not call non-public methods on EJB's
> ----------------------------------------------------------------------------
>
> Key: WFLY-5197
> URL: https://issues.jboss.org/browse/WFLY-5197
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 10.0.0.Beta2
> Reporter: Tomas Remes
> Assignee: Stuart Douglas
> Fix For: 10.0.0.CR1
>
>
> It's intermittently failing in CDI TCK in org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.LifecycleCallbackInterceptorTest. There is:
> {code}
> @Stateful
> @Interceptors(CatInterceptor.class)
> public class Cat extends Animal {
> ...
> @Override
> public void foo() {
> }
> ...
> }
> {code}
> and:
> {code}
> public abstract class Animal {
>
> ...
> void foo() {
> }
> ....
> }
> {code}
> There is check in {{org.jboss.as.ejb3.component.session.SessionBeanComponentDescription#addNoInterfaceView}} whether method is public. This check is sometimes called for {{Animal.foo()}} and sometimes for {{Cat.foo()}}. I think only {{Cat.foo()}} should be checked.
> Stacktrace is:
> {noformat}
> javax.ejb.EJBException: WFLYEJB0224: Not a business method void org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.Animal.foo(). Do not call non-public methods on EJB's
> at org.jboss.as.ejb3.component.session.NotBusinessMethodInterceptor.processInvocation(NotBusinessMethodInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> at org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.Cat$$$view2.foo(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> at org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.Cat$Proxy$_$$_Weld$EnterpriseProxy$.foo(Unknown Source)
> at org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.LifecycleCallbackInterceptorTest.createAndDestroyInstance(LifecycleCallbackInterceptorTest.java:87)
> at org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.LifecycleCallbackInterceptorTest.testLifecycleCallbackInterceptorTransactionContext(LifecycleCallbackInterceptorTest.java:137)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5210) Datasource configuration allows editing driver name to non-existing one
by Jan Kašík (JIRA)
[ https://issues.jboss.org/browse/WFLY-5210?page=com.atlassian.jira.plugin.... ]
Jan Kašík updated WFLY-5210:
----------------------------
Steps to Reproduce:
# Run Wildfly in domain mode
# Navigate to existing datasource, e.g.: Configuration -> Profiles -> full-ha -> Non-XA -> ExampleDS and click on {{View}}
# Disable datasource by clicking on {{Disable}} button
# Switch to {{Attributes}} tab
# Click on {{Edit}}
# Change value of {{Driver:}} field to {{qwerty}}
# Click on {{Save}} button
# Success message is showed instead of error as in case of addition
was:
# Run EAP 7 in domain mode
# Navigate to existing datasource, e.g.: Configuration -> Profiles -> full-ha -> Non-XA -> ExampleDS and click on {{View}}
# Disable datasource by clicking on {{Disable}} button
# Switch to {{Attributes}} tab
# Click on {{Edit}}
# Change value of {{Driver:}} field to {{qwerty}}
# Click on {{Save}} button
# Success message is showed instead of error as in case of addition
> Datasource configuration allows editing driver name to non-existing one
> -----------------------------------------------------------------------
>
> Key: WFLY-5210
> URL: https://issues.jboss.org/browse/WFLY-5210
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 10.0.0.Beta2
> Reporter: Jan Kašík
> Assignee: Heiko Braun
>
> When editing datasource attributes, JDBC driver name can be changed to driver which is not installed (deployed) without any error message being showed. Although error message "A driver needs to be specified or chosen!" is showed if driver, which is not present in system, is filled in form during addition of new datasource.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5210) Datasource configuration allows editing driver name to non-existing one
by Jan Kašík (JIRA)
[ https://issues.jboss.org/browse/WFLY-5210?page=com.atlassian.jira.plugin.... ]
Jan Kašík moved JBEAP-876 to WFLY-5210:
---------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5210 (was: JBEAP-876)
Workflow: GIT Pull Request workflow (was: CDW v1)
Affects Version/s: 10.0.0.Beta2
(was: 7.0.0.DR9)
Component/s: Web Console
(was: Web Console)
Target Release: (was: 7.0.0.GA)
> Datasource configuration allows editing driver name to non-existing one
> -----------------------------------------------------------------------
>
> Key: WFLY-5210
> URL: https://issues.jboss.org/browse/WFLY-5210
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 10.0.0.Beta2
> Reporter: Jan Kašík
> Assignee: Heiko Braun
>
> When editing datasource attributes, JDBC driver name can be changed to driver which is not installed (deployed) without any error message being showed. Although error message "A driver needs to be specified or chosen!" is showed if driver, which is not present in system, is filled in form during addition of new datasource.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
