[JBoss JIRA] (DROOLS-275) RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock)
by Duncan Doyle (JIRA)
Duncan Doyle created DROOLS-275:
-----------------------------------
Summary: RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock)
Key: DROOLS-275
URL: https://issues.jboss.org/browse/DROOLS-275
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.CR3
Environment: Mac OS-X 10.8.5, Hotspot 1.7.0_40
Reporter: Duncan Doyle
Assignee: Mark Proctor
I persist a KieSession via the Marshaller (serializable) with one fact/event inserted. On reload of the session, I can see that fact is still there (when I check the FactHandles) and the PseudoClock is at the correct time (the time when I persisted it). If I then insert another fact/event into this reloaded session which matches the following rule:
rule "SimpleFactTimeWindow"
when
$s1: SimpleFact() from entry-point LinkyStream
$s2: SimpleFact(this != $s1, this after [0s, 10s] $s1) from entry-point LinkyStream
then
System.out.println("Rule fired, found 2 Facts within the time window.");
end
I get a NPE (in both Phreak and ReteOO mode). Exception in Phreak:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.NullPointerException
at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedRight(AfterEvaluatorDefinition.java:304)
at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedRight(EvaluatorConstraint.java:80)
at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:117)
at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:150)
at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56)
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:335)
at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:162)
at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:117)
at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:65)
at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:936)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1183)
at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:910)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233)
at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:142)
at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
... 6 more
Exception in ReteOO:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
at java.lang.Thread.run(Thread.java:724)
Caused by: org.drools.core.RuntimeDroolsException: Unexpected exception executing action org.drools.core.reteoo.PropagationQueuingNode$PropagateAction@2e3aeda
at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1225)
at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:278)
at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:131)
at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:56)
at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:140)
at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
... 6 more
Caused by: java.lang.NullPointerException
at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedLeft(AfterEvaluatorDefinition.java:324)
at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedLeft(EvaluatorConstraint.java:67)
at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:108)
at org.drools.reteoo.nodes.ReteJoinNode.propagateFromLeft(ReteJoinNode.java:147)
at org.drools.reteoo.nodes.ReteJoinNode.assertLeftTuple(ReteJoinNode.java:99)
at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:213)
at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:73)
at org.drools.reteoo.nodes.ReteJoinNode.propagateFromRight(ReteJoinNode.java:135)
at org.drools.reteoo.nodes.ReteJoinNode.assertRightTuple(ReteJoinNode.java:125)
at org.drools.reteoo.nodes.ReteBetaNodeUtils.assertObject(ReteBetaNodeUtils.java:47)
at org.drools.reteoo.nodes.ReteJoinNode.assertObject(ReteJoinNode.java:39)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
at org.drools.core.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:430)
at org.drools.core.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:266)
at org.drools.core.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:592)
at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1223)
... 12 more
What I discovered is that this only happens when I save the KieSession to a file in one JVM and reload it in another. When I load the KieSession in the same JVM as the one in which I persisted it, there is no exception and the rule get's fired (as expected).
I created a reproducer project for it: https://github.com/DuncanDoyle/DroolsSessionPersistenceNPE/
I've added some Maven profiles so you can easily observe the behaviour:
- mvn -PallRuns exec:java : this runs both the persistence and the reload in the same JVM, no exception, everything works fine.
- mvn -PfirstRun exec:java : this runs the first part of the test, and saves the KieSession to a file.
- mvn -PsecondRun exec:java : this runs the second part of the test, which loads the previously saved KieSession from the file and inserts a new fact, resulting in the NPE.
All three tests can also be run in ReteOO mode by adding "-Ddrools.ruleEngine=reteoo" at the end of the command.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (JGRP-1707) MergeView: marshalling fails when subgroups are not a subset of members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1707?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1707.
----------------------------
Resolution: Done
> MergeView: marshalling fails when subgroups are not a subset of members
> -----------------------------------------------------------------------
>
> Key: JGRP-1707
> URL: https://issues.jboss.org/browse/JGRP-1707
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> When we have 2 partitions \{A,B,C\} and \{X,Y,Z\} and they merge, but one of the members (e.g. Z) is excluded from the merge (e.g. because it is involved in a different merge already), we create the following MergeView:
> {noformat}
> MergeView:
> view={A,B,C,X,Y}
> subgroups={A,B,C} {X,Y,Z}
> {noformat}
> Because the members of the subgroups refer to the merge view via index, the index for Z is -1, and thus - when unmarshalled - Z points to a null creator, which triggers the following stack trace:
> {noformat}
> 00631037-49819: failed handling incoming message
> java.lang.IllegalArgumentException: creator cannot be null
> at org.jgroups.ViewId.<init>(ViewId.java:32)
> at org.jgroups.ViewId.<init>(ViewId.java:42)
> at org.jgroups.View.create(View.java:90)
> at org.jgroups.MergeView.readFrom(MergeView.java:119)
> at org.jgroups.protocols.pbcast.GMS$GmsHeader.readFrom(GMS.java:1285)
> at org.jgroups.Message.readHeader(Message.java:889)
> at org.jgroups.Message.readFrom(Message.java:803)
> at org.jgroups.protocols.TP.readMessageBatch(TP.java:1796)
> at org.jgroups.protocols.TP.receive(TP.java:1463)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:683)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> SOLUTION:
> * When marshalling a MergeView, and a subgroup member has no corresponding member in {{members}}, then send the *address* instead of the index
> * OR: remove all members from subgroups which are not in {{members}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (WFLY-1916) Deployer role within domain
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFLY-1916?page=com.atlassian.jira.plugin.... ]
Heiko Braun updated WFLY-1916:
------------------------------
Parent: (was: WFLY-490)
Issue Type: Bug (was: Sub-task)
> Deployer role within domain
> ---------------------------
>
> Key: WFLY-1916
> URL: https://issues.jboss.org/browse/WFLY-1916
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
> Fix For: 8.0.0.Beta1
>
>
> There seems to be a problem with the deplyer role within the domain. In order to operate on doamin deployments, the deplyer requires write access to:
> a) /server-group=*
> b) /deployment=*
> But currently only the later seems to be given. This basically reduces the deployer role to just the abillity to upload contents, but not assign them to server-groups.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (JGRP-1707) MergeView: marshalling fails when subgroups are not a subset of members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1707?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1707:
--------------------------------
The second exception:
{noformat}
version = 6400 (3.4.0)
flags: OOB
java.lang.RuntimeException: class for magic number 9625 not found
at org.jgroups.util.Util.readOtherAddress(Util.java:967)
at org.jgroups.util.Util.readAddress(Util.java:911)
at org.jgroups.util.Util.readAddresses(Util.java:1038)
at org.jgroups.View.readFrom(View.java:190)
at org.jgroups.MergeView.readFrom(MergeView.java:108)
at org.jgroups.protocols.pbcast.GMS$GmsHeader.readFrom(GMS.java:1285)
at org.jgroups.Message.readHeader(Message.java:889)
at org.jgroups.Message.readFrom(Message.java:803)
at org.jgroups.protocols.TP.readMessageBatch(TP.java:1796)
at org.jgroups.tests.ParseMessages.parse(ParseMessages.java:56)
at org.jgroups.ParserPcap.main(ParserPcap.java:37)
{noformat}
is caused by a view of a subgroup not being read correctly. The code is here:
{code}
public void readFrom(DataInput in) throws Exception {
super.readFrom(in);
short len=in.readShort();
if(len > 0) {
subgroups=new View[len];
for(int i=0; i < len; i++) {
int index=in.readShort();
long id=in.readLong();
Address creator=get(index);
Address[] mbrs=new Address[in.readShort()];
for(int j=0; j < mbrs.length; j++)
mbrs[j]=get(in.readShort());
View view=View.create(creator, id, mbrs);
subgroups[i]=view;
}
}
}
{code}
When {{View.create()}} throws an exception, and there are more views in the subgroups, then we have unread data left, and parsing of the next header will fail.
SOLUTION: wrap {{View.create()}} in a try-catch clause and simply skip the view if an exception is thrown
> MergeView: marshalling fails when subgroups are not a subset of members
> -----------------------------------------------------------------------
>
> Key: JGRP-1707
> URL: https://issues.jboss.org/browse/JGRP-1707
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> When we have 2 partitions \{A,B,C\} and \{X,Y,Z\} and they merge, but one of the members (e.g. Z) is excluded from the merge (e.g. because it is involved in a different merge already), we create the following MergeView:
> {noformat}
> MergeView:
> view={A,B,C,X,Y}
> subgroups={A,B,C} {X,Y,Z}
> {noformat}
> Because the members of the subgroups refer to the merge view via index, the index for Z is -1, and thus - when unmarshalled - Z points to a null creator, which triggers the following stack trace:
> {noformat}
> 00631037-49819: failed handling incoming message
> java.lang.IllegalArgumentException: creator cannot be null
> at org.jgroups.ViewId.<init>(ViewId.java:32)
> at org.jgroups.ViewId.<init>(ViewId.java:42)
> at org.jgroups.View.create(View.java:90)
> at org.jgroups.MergeView.readFrom(MergeView.java:119)
> at org.jgroups.protocols.pbcast.GMS$GmsHeader.readFrom(GMS.java:1285)
> at org.jgroups.Message.readHeader(Message.java:889)
> at org.jgroups.Message.readFrom(Message.java:803)
> at org.jgroups.protocols.TP.readMessageBatch(TP.java:1796)
> at org.jgroups.protocols.TP.receive(TP.java:1463)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:683)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> SOLUTION:
> * When marshalling a MergeView, and a subgroup member has no corresponding member in {{members}}, then send the *address* instead of the index
> * OR: remove all members from subgroups which are not in {{members}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (WFLY-1569) Not possible to reload server when JTS transactions are activated
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1569:
-----------------------------------------------
tom.jenkinson(a)redhat.com made a comment on [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379]
For information: this has the same severity as 1009931, both are fixed in 4.17.11.
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
> Key: WFLY-1569
> URL: https://issues.jboss.org/browse/WFLY-1569
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.0.0.Alpha1
> Reporter: Ondřej Chaloupka
> Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
> - <jts/> tag under transactions subsystem
> - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
> at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)
> at org.jacorb.poa.POA.set_servant(POA.java:1979)
> at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement
> at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)
> ... 5 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months