[JBoss JIRA] (WFCORE-1049) ConcreteResourceRegistration#registerSubModel is not thread safe
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1049?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1049:
------------------------------------------
Making the method synchronized won't help, as the problem isn't concurrent calls to registerSubmodel. It's that registerSubmodel is publishing an incompletely initialized MRR making it visible to other threads before it has its attributes, operations and children registered. When I looked at the failures in the test, they were NPEs due to later code assuming that children would exist.
Unfortunately I can't remember the name of the failing test so I can't find the failures now. :( I'd like to find those as this will need a JBEAP and that will need some evidence as to how this is an actual problem users will see.
The pull request passes now.
BTW I'm not sure why I added the "check for existing and then register", as the registration itself is a putIfAbsent with a failure if that returns non-null. So the checkIfExisting seems redundant. But I don't think that caused the test failures. Not in the ones I looked at at least.
> ConcreteResourceRegistration#registerSubModel is not thread safe
> ----------------------------------------------------------------
>
> Key: WFCORE-1049
> URL: https://issues.jboss.org/browse/WFCORE-1049
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Stuart Douglas
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> registerSubModel checks for existing, then registers, however it is invoked by two threads at the same time it is possible they will both see the resource as not existing and both register.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5393) Using deprecated attribute use-hornetq-store in CLI does not have any effect being set
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-5393?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on WFLY-5393:
---------------------------------
Thanks [~ochaloup] for pointing it out and I will update the test to see if it passes the wildfly CI
> Using deprecated attribute use-hornetq-store in CLI does not have any effect being set
> --------------------------------------------------------------------------------------
>
> Key: WFLY-5393
> URL: https://issues.jboss.org/browse/WFLY-5393
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.0.0.CR1
> Reporter: Ondřej Chaloupka
> Assignee: Amos Feng
> Fix For: 10.0.0.Final
>
>
> Attribute {{use-hornetq-store}} was deprecated for EAP7 and {{use-journal-store}} should be used instead. But even the attribute is deprecated it still should provide its old functionality.
> I think that using {{use-hornetq-store}} would have the same effect as when {{use-journal-store}} is used.
> I would think that when one of the attribute is set then the other one should present the same settings.
> {code}
> /subsystem=transactions:read-attribute(name=use-hornetq-store)
> {
> "outcome" => "success",
> "result" => false
> }
> /subsystem=transactions:read-attribute(name=use-journal-store)
> {
> "outcome" => "success",
> "result" => false
> }
> /subsystem=transactions:write-attribute(name=use-journal-store, value=true)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-restart" => true,
> "process-state" => "restart-required"
> }
> }
> :shutdown(restart=true)
> {"outcome" => "success"}
> /subsystem=transactions:read-attribute(name=use-journal-store)
> {
> "outcome" => "success",
> "result" => true
> }
> /subsystem=transactions:read-attribute(name=use-hornetq-store)
> {
> "outcome" => "success",
> "result" => false
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1966) Specify logger name for LogRecord in JDKLogImpl
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1966?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1966:
---------------------------
Fix Version/s: 3.6.7
(was: 3.6.6)
Damn, this one fell through the cracks !
> Specify logger name for LogRecord in JDKLogImpl
> -----------------------------------------------
>
> Key: JGRP-1966
> URL: https://issues.jboss.org/browse/JGRP-1966
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.6.6
> Reporter: George Zalizko
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
>
> I use Spring Boot with logback.
> For logging I have pattern:
> {code}%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} %C{30}:%L - %msg%n{code}
> And in console I see:
> {code}
> 16:19:32.062 [OOB-1,yphis-cluster-web,George-THINKPAD-35404] WARN unknown.jul.logger org.jgroups.logging.JDKLogImpl:49 - JGRP000010: packet from 192.168.50.123:45588 has different version (3.2.8) than ours (3.6.6); packet is discarded{code}
> This happens because LogRecord created in org.jgroups.logging.JDKLogImpl doesn't have loggerName and when org.slf4j.bridge.SLF4JBridgeHandler make org.slf4j.Logger from java.util.logging.LogRecord he sets logger name as org.slf4j.bridge.SLF4JBridgeHandler#UNKNOWN_LOGGER_NAME that's "unknown.jul.logger"
> Actually I don't know is it done specially or not, but I can't find any comments/solutions for that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5642) RejectedExecutionException when deploying in test org.jboss.as.test.clustering.cluster.web.ClusteredWebSimpleTestCase.testGracefulServeOnUndeploy
by Ivan Straka (JIRA)
Ivan Straka created WFLY-5642:
---------------------------------
Summary: RejectedExecutionException when deploying in test org.jboss.as.test.clustering.cluster.web.ClusteredWebSimpleTestCase.testGracefulServeOnUndeploy
Key: WFLY-5642
URL: https://issues.jboss.org/browse/WFLY-5642
Project: WildFly
Issue Type: Bug
Components: Clustering, Test Suite
Reporter: Ivan Straka
Assignee: Paul Ferraro
org.jboss.as.test.clustering.cluster.web.ClusteredWebSimpleTestCase is failing.
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-tcpgossip-mav...
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-tcpgossip-mav... && x86_64 && eap-sustaining/testReport/org.jboss.as.test.clustering.cluster.web/ClusteredWebSimpleTestCase(SYNC-tcp)/testGracefulServeOnUndeploy/
WARN [org.wildfly.clustering.web.infinispan] (default task-18) WFLYCLWEBINF0006: Failed to schedule expiration/passivation of session PShvmFq6MDIrMz1wZP6MwVHydgu6_EMrtMyLm_x6 on primary owner.: java.util.concurrent.ExecutionException: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@24aaa062 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@2095202f[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
at org.wildfly.clustering.server.dispatcher.SimpleCommandResponse.<init>(SimpleCommandResponse.java:43)
at org.wildfly.clustering.server.dispatcher.LocalCommandDispatcher.executeOnNode(LocalCommandDispatcher.java:82)
at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcher.executeOnNode(ChannelCommandDispatcher.java:146)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.lambda$executeOnPrimaryOwner$5(InfinispanSessionManager.java:195)
at org.wildfly.clustering.ee.infinispan.RetryingInvoker.invoke(RetryingInvoker.java:70)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.executeOnPrimaryOwner(InfinispanSessionManager.java:192)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.schedule(InfinispanSessionManager.java:185)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.close(InfinispanSessionManager.java:462)
at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:75)
at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:767)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:554)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:788)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@24aaa062 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@2095202f[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
at org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler.schedule(SessionExpirationScheduler.java:101)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.lambda$schedule$0(InfinispanSessionManager.java:138)
at java.util.ArrayList.forEach(ArrayList.java:1249)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.schedule(InfinispanSessionManager.java:138)
at org.wildfly.clustering.web.infinispan.session.ScheduleSchedulerCommand.execute(ScheduleSchedulerCommand.java:48)
at org.wildfly.clustering.web.infinispan.session.ScheduleSchedulerCommand.execute(ScheduleSchedulerCommand.java:35)
at org.wildfly.clustering.server.dispatcher.LocalCommandDispatcher.executeOnNode(LocalCommandDispatcher.java:80)
... 18 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5642) RejectedExecutionException when deploying in test org.jboss.as.test.clustering.cluster.web.ClusteredWebSimpleTestCase.testGracefulServeOnUndeploy
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5642?page=com.atlassian.jira.plugin.... ]
Ivan Straka updated WFLY-5642:
------------------------------
Affects Version/s: 10.0.0.CR4
> RejectedExecutionException when deploying in test org.jboss.as.test.clustering.cluster.web.ClusteredWebSimpleTestCase.testGracefulServeOnUndeploy
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5642
> URL: https://issues.jboss.org/browse/WFLY-5642
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.CR4
> Reporter: Ivan Straka
> Assignee: Paul Ferraro
>
> org.jboss.as.test.clustering.cluster.web.ClusteredWebSimpleTestCase is failing.
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-tcpgossip-mav...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-tcpgossip-mav... && x86_64 && eap-sustaining/testReport/org.jboss.as.test.clustering.cluster.web/ClusteredWebSimpleTestCase(SYNC-tcp)/testGracefulServeOnUndeploy/
> WARN [org.wildfly.clustering.web.infinispan] (default task-18) WFLYCLWEBINF0006: Failed to schedule expiration/passivation of session PShvmFq6MDIrMz1wZP6MwVHydgu6_EMrtMyLm_x6 on primary owner.: java.util.concurrent.ExecutionException: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@24aaa062 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@2095202f[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> at org.wildfly.clustering.server.dispatcher.SimpleCommandResponse.<init>(SimpleCommandResponse.java:43)
> at org.wildfly.clustering.server.dispatcher.LocalCommandDispatcher.executeOnNode(LocalCommandDispatcher.java:82)
> at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcher.executeOnNode(ChannelCommandDispatcher.java:146)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.lambda$executeOnPrimaryOwner$5(InfinispanSessionManager.java:195)
> at org.wildfly.clustering.ee.infinispan.RetryingInvoker.invoke(RetryingInvoker.java:70)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.executeOnPrimaryOwner(InfinispanSessionManager.java:192)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.schedule(InfinispanSessionManager.java:185)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.close(InfinispanSessionManager.java:462)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:75)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:767)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:554)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:788)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@24aaa062 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@2095202f[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
> at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
> at org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler.schedule(SessionExpirationScheduler.java:101)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.lambda$schedule$0(InfinispanSessionManager.java:138)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.schedule(InfinispanSessionManager.java:138)
> at org.wildfly.clustering.web.infinispan.session.ScheduleSchedulerCommand.execute(ScheduleSchedulerCommand.java:48)
> at org.wildfly.clustering.web.infinispan.session.ScheduleSchedulerCommand.execute(ScheduleSchedulerCommand.java:35)
> at org.wildfly.clustering.server.dispatcher.LocalCommandDispatcher.executeOnNode(LocalCommandDispatcher.java:80)
> ... 18 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5566) org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5566?page=com.atlassian.jira.plugin.... ]
Ivan Straka updated WFLY-5566:
------------------------------
Steps to Reproduce:
change jboss-eap-7.0/standalone/configuration/standalone-ha.xml and jboss-eap-7.0/standalone/configuration/standalone-full-ha.xml so that tcpgossip protocol will be used to make cluster:
{code:xml}
<subsystem xmlns="urn:jboss:domain:jgroups:4.0">
<channels default="ee">
<channel stack="tcp" name="ee"/>
</channels>
<stacks>
<stack name="udp">
NO CHANGE
</stack>
<stack name="tcp">
<transport socket-binding="jgroups-tcp" type="TCP"/>
<protocol type="TCPGOSSIP" xmlns="urn:jboss:domain:jgroups:4.0">
<property name="initial_hosts">localhost[12011]</property>
<property name="num_initial_members">2</property>
</protocol>
<protocol type="MERGE3"/>
<protocol socket-binding="jgroups-tcp-fd" type="FD_SOCK"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
</stacks>
</subsystem>
{code}
run tcpgossip router
java -cp `pwd`/jboss-eap-7.0/modules/system/layers/base/org/jboss/logging/main/jboss-logging-3.3.0.Final.jar:`pwd`/jboss-eap-7.0/modules/system/layers/base/org/jgroups/main/jgroups-3.6.6.Final.jar org.jgroups.stack.GossipRouter -port 12011 -bindaddress localhost -solinger 0 -sotimeout 0 -expiry 0
run testsuite
./integration-tests.sh -fae -s `pwd`/tools/maven/conf/settings.xml -Dts.clustering -Dts.noSmoke -DextendedTests -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dmcast=$MCAST_ADDR -Djboss.dist=`pwd`/jboss-eap-7.0 -Dmaven.repo.local=`pwd`/eap-local-maven-repository -Dtest=\*XSiteSimpleTestCase\*
was:
change jboss-eap-7.0/standalone/configuration/standalone-ha.xml and jboss-eap-7.0/standalone/configuration/standalone-full-ha.xml so that jgroups protocol will be used to make cluster:
{code:xml}
<subsystem xmlns="urn:jboss:domain:jgroups:4.0">
<channels default="ee">
<channel stack="tcp" name="ee"/>
</channels>
<stacks>
<stack name="udp">
NO CHANGE
</stack>
<stack name="tcp">
<transport socket-binding="jgroups-tcp" type="TCP"/>
<protocol type="TCPGOSSIP" xmlns="urn:jboss:domain:jgroups:4.0">
<property name="initial_hosts">localhost[12011]</property>
<property name="num_initial_members">2</property>
</protocol>
<protocol type="MERGE3"/>
<protocol socket-binding="jgroups-tcp-fd" type="FD_SOCK"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
</stacks>
</subsystem>
{code}
run tcpgossip router
java -cp `pwd`/jboss-eap-7.0/modules/system/layers/base/org/jboss/logging/main/jboss-logging-3.3.0.Final.jar:`pwd`/jboss-eap-7.0/modules/system/layers/base/org/jgroups/main/jgroups-3.6.6.Final.jar org.jgroups.stack.GossipRouter -port 12011 -bindaddress localhost -solinger 0 -sotimeout 0 -expiry 0
run testsuite
./integration-tests.sh -fae -s `pwd`/tools/maven/conf/settings.xml -Dts.clustering -Dts.noSmoke -DextendedTests -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dmcast=$MCAST_ADDR -Djboss.dist=`pwd`/jboss-eap-7.0 -Dmaven.repo.local=`pwd`/eap-local-maven-repository -Dtest=\*XSiteSimpleTestCase\*
> org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
> --------------------------------------------------------------------------------
>
> Key: WFLY-5566
> URL: https://issues.jboss.org/browse/WFLY-5566
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.CR2
> Reporter: Ivan Straka
> Assignee: Paul Ferraro
>
> There is org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed failing with exception:
> {code:java}
> Error Message
> expected:<500> but was:<200>
> Stacktrace
> java.lang.AssertionError: expected:<500> but was:<200>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutToBackupNotRelayed(XSiteSimpleTestCase.java:202)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-844) Crash when node is deleted from query node
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-844?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-844.
--------------------------------
Fix Version/s: 6.4.x
Resolution: Done
We did a number of fixes on this regards. I'm rerunning the reproducer you sent and now I'm not getting any exception, so I believe that the problem you reported is also solved even if at the moment I'm not able to find which specific commit fixed it.
Please rerun your use case against 6.3.0.Final (or even better master if possible) and confirm if this is ok also for you. I'm closing this ticket for now, but feel free to reopen it in case you will find any other issue.
> Crash when node is deleted from query node
> ------------------------------------------
>
> Key: DROOLS-844
> URL: https://issues.jboss.org/browse/DROOLS-844
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Beta2
> Reporter: Fabian Meyer
> Assignee: Mario Fusco
> Priority: Critical
> Fix For: 6.4.x
>
>
> When a left delete is performed on a PhreakQueryNode, the fact handle of the left tuple might be null, resulting in a NullPointerException.
> Exception in thread "Thread-6" java.lang.NullPointerException
> at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:176)
> at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:46)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:460)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:360)
> at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:598)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:524)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:336)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:973)
> at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1251)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1353)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1331)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months