[JBoss JIRA] (DROOLS-951) Removing 2 or more rules does not retract justified objects
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-951?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-951:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1273087|https://bugzilla.redhat.com/show_bug.cgi?id=1273087] from ON_QA to ASSIGNED
> Removing 2 or more rules does not retract justified objects
> -----------------------------------------------------------
>
> Key: DROOLS-951
> URL: https://issues.jboss.org/browse/DROOLS-951
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Zvonimir Bošnjak
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
>
> When removing rules from knowledge which have logically inserted (justified) objects, only one object (from first removed rule) will be retracted.
> In example from AddRemoveRule#184: as it removes the first rule, it re-initializes all other path memories and, in particular, marks them as unlinked (AbstractTerminalNode#204)
> Later, when it tries to flush the deletions (AddRemoveRule#280), the unlinked status prevents the propagation from taking place.
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-930) ClassCastException after segment split during incremental compilation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-930?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-930:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1273087|https://bugzilla.redhat.com/show_bug.cgi?id=1273087] from ON_QA to ASSIGNED
> ClassCastException after segment split during incremental compilation
> ---------------------------------------------------------------------
>
> Key: DROOLS-930
> URL: https://issues.jboss.org/browse/DROOLS-930
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
>
> A segment split during an incremental compilation as in the following test case
> {code}
> @Test
> public void testSegmentSplitOnIncrementalCompilation() throws Exception {
> String drl =
> "import " + Person.class.getCanonicalName() + "\n" +
> "rule R1 when\n" +
> " $s : String()" +
> " Person( name == $s ) \n" +
> "then\n" +
> " System.out.println(\"Triggered: R1\");\n" +
> "end\n" +
> "rule R2 when\n" +
> " $s : String()" +
> " Person( name == $s ) \n" +
> "then\n" +
> " System.out.println(\"Triggered: R2\");\n" +
> "end\n" +
> "rule R3 when\n" +
> " $s : String()" +
> " Person( name != $s ) \n" +
> "then\n" +
> " System.out.println(\"Triggered: R3\");\n" +
> "end\n";
> KieServices ks = KieServices.Factory.get();
> ReleaseId releaseId1 = ks.newReleaseId("org.kie", "test-upgrade", "1.1.1");
> KieModule km = createAndDeployJar(ks, releaseId1);
> KieContainer kc = ks.newKieContainer(km.getReleaseId());
> KieSession ksession = kc.newKieSession();
> kc.updateToVersion(releaseId1);
> ksession.insert(new Person("John", 26));
> ksession.insert( "John" );
> ksession.fireAllRules();
> ReleaseId releaseId2 = ks.newReleaseId("org.kie", "test-upgrade", "1.1.2");
> km = createAndDeployJar(ks, releaseId2, drl);
> kc.updateToVersion(releaseId2);
> ksession.fireAllRules();
> }
> {code}
> may cause the following ClassCastException during the subsequent network evaluation
> {code}
> java.lang.ClassCastException: org.drools.core.reteoo.RuleTerminalNode cannot be cast to org.drools.core.reteoo.LeftInputAdapterNode
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:99)
> 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:978)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
> at org.drools.compiler.integrationtests.IncrementalCompilationTest.testSegmentSplit(IncrementalCompilationTest.java:2001)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-891) Missing alpha node removal when the only rule using it is removed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-891?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-891:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1273087|https://bugzilla.redhat.com/show_bug.cgi?id=1273087] from ON_QA to ASSIGNED
> Missing alpha node removal when the only rule using it is removed
> -----------------------------------------------------------------
>
> Key: DROOLS-891
> URL: https://issues.jboss.org/browse/DROOLS-891
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.3.0.CR2
>
>
> When an alpha node has more than one sink and it is used by only one rule doesn't get removed when the rule itself is removed. The following test case demonstrates the problem.
> {code}
> @Test
> public void testRemoveHasSameConElement() {
> String packageName = "test";
> String rule1 = "package " + packageName + ";" +
> "import java.util.Map; \n" +
> "rule 'rule1' \n" +
> "when \n" +
> " Map(this['type'] == 'Goods' && this['brand'] == 'a') \n" +
> " Map(this['type'] == 'Goods' && this['category'] == 'b') \n" +
> "then \n" +
> "System.out.println('test rule 1'); \n"+
> "end";
> KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.add( ResourceFactory.newByteArrayResource( rule1.getBytes() ), ResourceType.DRL );
> if ( kbuilder.hasErrors() ) {
> fail( kbuilder.getErrors().toString() );
> }
> KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
> kbase.addKnowledgePackages( kbuilder.getKnowledgePackages() );
> kbase.removeKnowledgePackage(packageName);
> StatelessKnowledgeSession session = kbase.newStatelessKnowledgeSession();
> session.execute(new HashMap());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5574) org.wildfly.test.extension.rts InboundBridgeTestCase failing when transaction uses JTS
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-5574?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-5574:
--------------------------------
Fix Version/s: 11.0.0.CR1
(was: 10.0.0.Final)
> org.wildfly.test.extension.rts InboundBridgeTestCase failing when transaction uses JTS
> --------------------------------------------------------------------------------------
>
> Key: WFLY-5574
> URL: https://issues.jboss.org/browse/WFLY-5574
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Transactions
> Affects Versions: 10.0.0.CR3
> Reporter: Ondřej Chaloupka
> Assignee: Gytis Trikleris
> Fix For: 11.0.0.CR1
>
> Attachments: server.log
>
>
> There is failures in testcase org.wildfly.test.extension.rts.InboundBridgeTestCase when transaction uses JTS.
> Example of the failure
> {code}
> testCommit(org.wildfly.test.extension.rts.InboundBridgeTestCase) Time elapsed: 2.54 sec <<< FAILURE!
> java.lang.AssertionError: expected:<4> but was:<5>
> {code}
> The JBOSS_HOME distribution is change to transaction to be run with JTS: changing the {{docs/example/standalone-rts.xml}} to switch transactions parameter in iiop orb subsystem to {{full}} and adding {{jts}} element to transactions subsystem.
> When JBOSS_HOME is set then I've run the test in this way
> {{./integration-tests.sh clean install -Dts.noSmoke -Dts.rts -Djboss.dist=$JBOSS_HOME -Dtest=InboundBridgeTestCase}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5705) Cluster is not created using TCPGOSSIP
by Ivan Straka (JIRA)
Ivan Straka created WFLY-5705:
---------------------------------
Summary: Cluster is not created using TCPGOSSIP
Key: WFLY-5705
URL: https://issues.jboss.org/browse/WFLY-5705
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Ivan Straka
Assignee: Paul Ferraro
Priority: Minor
If gossip router is bound to localhost and nodes are not, they won't make cluster. But if nodes are bound to localhost and only port offset is used, they will make cluster.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months