[JBoss JIRA] (DROOLS-3228) Rules don't produce the correct result anymore after a session reset
by Christian Liebhardt (Jira)
[ https://issues.jboss.org/browse/DROOLS-3228?page=com.atlassian.jira.plugi... ]
Christian Liebhardt updated DROOLS-3228:
----------------------------------------
Description:
Hello,
A while ago I've created a test projects to compare the different possibilities of session types and session polling/reusing. After an update to Drools 7.13.0.Final I found a performance improvement but also two issues. I would summarize both issues in this ticket as the second one is really minor. Let me know if you have a different preference. Also I'm adding code changes to the ticket description. If you like I can also create a pull request for that. The reason why I hesitated to do this right away is that I'm unclear regarding the solution of the first issue.
*1. Incorrect results*
If you clone the project and execute [StatefulDroolsEngineUnitTest.java|https://github.com/liebharc/JavaRules/b...] then you will see test failures with 7.13.0.Final while the tests pass with 7.12.0.Final. I could trace the issue back to a recent change in ConcurrentNodeMemories. If I revert this change on a snapshot build of 7.14.0 then the tests pass again. Here the patch for the revert:
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
index 020446190c..48045697af 100644
---
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
+++
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
@@ -16,6 +16,8 @@
package org.drools.core.common;
+import java.util.HashSet;
+import java.util.Set;
import java.util.concurrent.atomic.AtomicReferenceArray;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
@@ -53,20 +55,24 @@ public class ConcurrentNodeMemories implements NodeMemories {
public void resetAllMemories(StatefulKnowledgeSession session) {
InternalKnowledgeBase kBase = (InternalKnowledgeBase)session.getKieBase();
+ Set<SegmentMemory> smems = new HashSet<SegmentMemory>();
for (int i = 0; i < memories.length(); i++) {
Memory memory = memories.get(i);
if (memory != null) {
if (memory.getSegmentMemory() != null) {
- SegmentMemory smem = memory.getSegmentMemory();
- smem.reset(kBase.getSegmentPrototype(smem));
- if ( smem.isSegmentLinked() ) {
- smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
- }
+ smems.add(memory.getSegmentMemory());
}
memory.reset();
}
}
+
+ for (SegmentMemory smem : smems) {
+ smem.reset(kBase.getSegmentPrototype(smem));
+ if ( smem.isSegmentLinked() ) {
+ smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
+ }
+ }
}
/**
{code}
I tried to find out why the order matters here, but apparently lack knowledge.
*2. Reset doesn't bring a disposed session back to life*
With 7.12.0.Final it was possible to bring a disposed session back to life by calling the reset method. In 7.13.0.Final that doesn't work anymore because the checkAlive validation then fails.
The new session pools seem to deal with that by just setting the alive flag back to true if a session is reused. While the new session pools are great, we would like to stick with our existing and simpler session pooling which makes use of the reset method. So would it be possible to set the alive flag to true on a session reset?
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
index d6f4959e0d..4a6199ad23 100644
---
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
+++
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
@@ -1122,6 +1122,8 @@ public class StatefulKnowledgeSessionImpl extends
AbstractRuntime
this.processRuntime = null;
this.initialFactHandle = initInitialFact(kBase, null);
+
+ this.alive = true;
}
public void reset(int handleId,
{code}
was:
Hello,
A while ago I've created a test projects to compare the different possibilities of session types and session polling/reusing. After an update to Drools 7.13.0.Final I found a performance improvement but also two issues. I would summarize both issues in this ticket as the second one is really minor. Let me know if you have a different preference. Also I'm adding code changes to the ticket description. If you like I can also create a pull request for that. The reason why I hesitated to do this right away is that I'm unclear regarding the solution of the first issue.
*1. Incorrect results*
If you clone the project and execute [StatefulDroolsEngineUnitTest.java|https://github.com/liebharc/JavaRules/b...] then you will see test failures with 7.13.0.Final while the tests pass with 7.12.0.Final. I could trace the issue back to a recent change in ConcurrentNodeMemories. If I revert this change on a snapshot build of 7.14.0 then the tests pass again. Here the patch for the revert:
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
index 020446190c..48045697af 100644
---
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
+++
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
@@ -16,6 +16,8 @@
package org.drools.core.common;
+import java.util.HashSet;
+import java.util.Set;
import java.util.concurrent.atomic.AtomicReferenceArray;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
@@ -53,20 +55,24 @@ public class ConcurrentNodeMemories implements NodeMemories {
public void resetAllMemories(StatefulKnowledgeSession session) {
InternalKnowledgeBase kBase = (InternalKnowledgeBase)session.getKieBase();
+ Set<SegmentMemory> smems = new HashSet<SegmentMemory>();
for (int i = 0; i < memories.length(); i++) {
Memory memory = memories.get(i);
if (memory != null) {
if (memory.getSegmentMemory() != null) {
- SegmentMemory smem = memory.getSegmentMemory();
- smem.reset(kBase.getSegmentPrototype(smem));
- if ( smem.isSegmentLinked() ) {
- smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
- }
+ smems.add(memory.getSegmentMemory());
}
memory.reset();
}
}
+
+ for (SegmentMemory smem : smems) {
+ smem.reset(kBase.getSegmentPrototype(smem));
+ if ( smem.isSegmentLinked() ) {
+ smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
+ }
+ }
}
/**
{code}
I tried to find out why the order matters here, but apparently lack knowledge here.
*2. Reset doesn't bring a disposed session back to life*
With 7.12.0.Final it was possible to bring a disposed session back to life by calling the reset method. In 7.13.0.Final that doesn't work anymore because the checkAlive validation then fails.
The new session pools seem to deal with that by just setting the alive flag back to true if a session is reused. While the new session pools are great, we would like to stick with our existing and simpler session pooling which makes use of the reset method. So would it be possible to set the alive flag to true on a session reset?
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
index d6f4959e0d..4a6199ad23 100644
---
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
+++
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
@@ -1122,6 +1122,8 @@ public class StatefulKnowledgeSessionImpl extends
AbstractRuntime
this.processRuntime = null;
this.initialFactHandle = initInitialFact(kBase, null);
+
+ this.alive = true;
}
public void reset(int handleId,
{code}
> Rules don't produce the correct result anymore after a session reset
> --------------------------------------------------------------------
>
> Key: DROOLS-3228
> URL: https://issues.jboss.org/browse/DROOLS-3228
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.13.0.Final
> Reporter: Christian Liebhardt
> Assignee: Mario Fusco
> Priority: Major
>
> Hello,
> A while ago I've created a test projects to compare the different possibilities of session types and session polling/reusing. After an update to Drools 7.13.0.Final I found a performance improvement but also two issues. I would summarize both issues in this ticket as the second one is really minor. Let me know if you have a different preference. Also I'm adding code changes to the ticket description. If you like I can also create a pull request for that. The reason why I hesitated to do this right away is that I'm unclear regarding the solution of the first issue.
> *1. Incorrect results*
> If you clone the project and execute [StatefulDroolsEngineUnitTest.java|https://github.com/liebharc/JavaRules/b...] then you will see test failures with 7.13.0.Final while the tests pass with 7.12.0.Final. I could trace the issue back to a recent change in ConcurrentNodeMemories. If I revert this change on a snapshot build of 7.14.0 then the tests pass again. Here the patch for the revert:
> {code:java}
> diff --git
> a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> index 020446190c..48045697af 100644
> ---
> a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> +++
> b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> @@ -16,6 +16,8 @@
> package org.drools.core.common;
> +import java.util.HashSet;
> +import java.util.Set;
> import java.util.concurrent.atomic.AtomicReferenceArray;
> import java.util.concurrent.locks.Lock;
> import java.util.concurrent.locks.ReentrantLock;
> @@ -53,20 +55,24 @@ public class ConcurrentNodeMemories implements NodeMemories {
> public void resetAllMemories(StatefulKnowledgeSession session) {
> InternalKnowledgeBase kBase = (InternalKnowledgeBase)session.getKieBase();
> + Set<SegmentMemory> smems = new HashSet<SegmentMemory>();
> for (int i = 0; i < memories.length(); i++) {
> Memory memory = memories.get(i);
> if (memory != null) {
> if (memory.getSegmentMemory() != null) {
> - SegmentMemory smem = memory.getSegmentMemory();
> - smem.reset(kBase.getSegmentPrototype(smem));
> - if ( smem.isSegmentLinked() ) {
> - smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
> - }
> + smems.add(memory.getSegmentMemory());
> }
> memory.reset();
> }
> }
> +
> + for (SegmentMemory smem : smems) {
> + smem.reset(kBase.getSegmentPrototype(smem));
> + if ( smem.isSegmentLinked() ) {
> + smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
> + }
> + }
> }
> /**
> {code}
> I tried to find out why the order matters here, but apparently lack knowledge.
> *2. Reset doesn't bring a disposed session back to life*
> With 7.12.0.Final it was possible to bring a disposed session back to life by calling the reset method. In 7.13.0.Final that doesn't work anymore because the checkAlive validation then fails.
> The new session pools seem to deal with that by just setting the alive flag back to true if a session is reused. While the new session pools are great, we would like to stick with our existing and simpler session pooling which makes use of the reset method. So would it be possible to set the alive flag to true on a session reset?
> {code:java}
> diff --git
> a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> index d6f4959e0d..4a6199ad23 100644
> ---
> a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> +++
> b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> @@ -1122,6 +1122,8 @@ public class StatefulKnowledgeSessionImpl extends
> AbstractRuntime
> this.processRuntime = null;
> this.initialFactHandle = initInitialFact(kBase, null);
> +
> + this.alive = true;
> }
> public void reset(int handleId,
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3228) Rules don't produce the correct result anymore after a session reset
by Christian Liebhardt (Jira)
[ https://issues.jboss.org/browse/DROOLS-3228?page=com.atlassian.jira.plugi... ]
Christian Liebhardt updated DROOLS-3228:
----------------------------------------
Description:
Hello,
A while ago I've created a test projects to compare the different possibilities of session types and session polling/reusing. After an update to Drools 7.13.0.Final I found a performance improvement but also two issues. I would summarize both issues in this ticket as the second one is really minor. Let me know if you have a different preference. Also I'm adding code changes to the ticket description. If you like I can also create a pull request for that. The reason why I hesitated to do this right away is that I'm unclear regarding the solution of the first issue.
*1. Incorrect results*
If you clone the project and execute [StatefulDroolsEngineUnitTest.java|https://github.com/liebharc/JavaRules/b...] then you will see test failures with 7.13.0.Final while the tests pass with 7.12.0.Final. I could trace the issue back to a recent change in ConcurrentNodeMemories. If I revert this change on a snapshot build of 7.14.0 then the tests pass again. Here the patch for the revert:
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
index 020446190c..48045697af 100644
---
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
+++
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
@@ -16,6 +16,8 @@
package org.drools.core.common;
+import java.util.HashSet;
+import java.util.Set;
import java.util.concurrent.atomic.AtomicReferenceArray;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
@@ -53,20 +55,24 @@ public class ConcurrentNodeMemories implements NodeMemories {
public void resetAllMemories(StatefulKnowledgeSession session) {
InternalKnowledgeBase kBase = (InternalKnowledgeBase)session.getKieBase();
+ Set<SegmentMemory> smems = new HashSet<SegmentMemory>();
for (int i = 0; i < memories.length(); i++) {
Memory memory = memories.get(i);
if (memory != null) {
if (memory.getSegmentMemory() != null) {
- SegmentMemory smem = memory.getSegmentMemory();
- smem.reset(kBase.getSegmentPrototype(smem));
- if ( smem.isSegmentLinked() ) {
- smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
- }
+ smems.add(memory.getSegmentMemory());
}
memory.reset();
}
}
+
+ for (SegmentMemory smem : smems) {
+ smem.reset(kBase.getSegmentPrototype(smem));
+ if ( smem.isSegmentLinked() ) {
+ smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
+ }
+ }
}
/**
{code}
I tried to find out why the order matters here, but apparently lack knowledge here.
*2. Reset doesn't bring a disposed session back to life*
With 7.12.0.Final it was possible to bring a disposed session back to life by calling the reset method. In 7.13.0.Final that doesn't work anymore because the checkAlive validation then fails.
The new session pools seem to deal with that by just setting the alive flag back to true if a session is reused. While the new session pools are great, we would like to stick with our existing and simpler session pooling which makes use of the reset method. So would it be possible to set the alive flag to true on a session reset?
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
index d6f4959e0d..4a6199ad23 100644
---
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
+++
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
@@ -1122,6 +1122,8 @@ public class StatefulKnowledgeSessionImpl extends
AbstractRuntime
this.processRuntime = null;
this.initialFactHandle = initInitialFact(kBase, null);
+
+ this.alive = true;
}
public void reset(int handleId,
{code}
was:
Hello,
A while ago I've created a test projects to compare the different possibilities of session types and session polling/reusing. After an update to Drools 7.13.0.Final I found a performance improvement but also two issues. I would summarize both issues in this ticket as the second one is really minor. Let me know if you have a different preference. Also I'm adding code changes to the ticket description. If you like I can also create a pull request for that. The reason why I hesitated to do this right away is that I'm unclear regarding the solution of the first issue.
1. Incorrect results
If you clone the project and execute [StatefulDroolsEngineUnitTest.java|https://github.com/liebharc/JavaRules/b...] then you will see test failures with 7.13.0.Final while the tests pass with 7.12.0.Final. I could trace the issue back to a recent change in ConcurrentNodeMemories. If I revert this change on a snapshot build of 7.14.0 then the tests pass again. Here the patch for the revert:
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
index 020446190c..48045697af 100644
---
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
+++
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
@@ -16,6 +16,8 @@
package org.drools.core.common;
+import java.util.HashSet;
+import java.util.Set;
import java.util.concurrent.atomic.AtomicReferenceArray;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
@@ -53,20 +55,24 @@ public class ConcurrentNodeMemories implements NodeMemories {
public void resetAllMemories(StatefulKnowledgeSession session) {
InternalKnowledgeBase kBase = (InternalKnowledgeBase)session.getKieBase();
+ Set<SegmentMemory> smems = new HashSet<SegmentMemory>();
for (int i = 0; i < memories.length(); i++) {
Memory memory = memories.get(i);
if (memory != null) {
if (memory.getSegmentMemory() != null) {
- SegmentMemory smem = memory.getSegmentMemory();
- smem.reset(kBase.getSegmentPrototype(smem));
- if ( smem.isSegmentLinked() ) {
- smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
- }
+ smems.add(memory.getSegmentMemory());
}
memory.reset();
}
}
+
+ for (SegmentMemory smem : smems) {
+ smem.reset(kBase.getSegmentPrototype(smem));
+ if ( smem.isSegmentLinked() ) {
+ smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
+ }
+ }
}
/**
{code}
I tried to find out why the order matters here, but apparently lack knowledge here.
2. Reset doesn't bring a disposed session back to life
With 7.12.0.Final it was possible to bring a disposed session back to life by calling the reset method. In 7.13.0.Final that doesn't work anymore because the checkAlive validation then fails.
The new session pools seem to deal with that by just setting the alive flag back to true if a session is reused. While the new session pools are great, we would like to stick with our existing and simpler session pooling which makes use of the reset method. So would it be possible to set the alive flag to true on a session reset?
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
index d6f4959e0d..4a6199ad23 100644
---
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
+++
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
@@ -1122,6 +1122,8 @@ public class StatefulKnowledgeSessionImpl extends
AbstractRuntime
this.processRuntime = null;
this.initialFactHandle = initInitialFact(kBase, null);
+
+ this.alive = true;
}
public void reset(int handleId,
{code}
> Rules don't produce the correct result anymore after a session reset
> --------------------------------------------------------------------
>
> Key: DROOLS-3228
> URL: https://issues.jboss.org/browse/DROOLS-3228
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.13.0.Final
> Reporter: Christian Liebhardt
> Assignee: Mario Fusco
> Priority: Major
>
> Hello,
> A while ago I've created a test projects to compare the different possibilities of session types and session polling/reusing. After an update to Drools 7.13.0.Final I found a performance improvement but also two issues. I would summarize both issues in this ticket as the second one is really minor. Let me know if you have a different preference. Also I'm adding code changes to the ticket description. If you like I can also create a pull request for that. The reason why I hesitated to do this right away is that I'm unclear regarding the solution of the first issue.
> *1. Incorrect results*
> If you clone the project and execute [StatefulDroolsEngineUnitTest.java|https://github.com/liebharc/JavaRules/b...] then you will see test failures with 7.13.0.Final while the tests pass with 7.12.0.Final. I could trace the issue back to a recent change in ConcurrentNodeMemories. If I revert this change on a snapshot build of 7.14.0 then the tests pass again. Here the patch for the revert:
> {code:java}
> diff --git
> a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> index 020446190c..48045697af 100644
> ---
> a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> +++
> b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> @@ -16,6 +16,8 @@
> package org.drools.core.common;
> +import java.util.HashSet;
> +import java.util.Set;
> import java.util.concurrent.atomic.AtomicReferenceArray;
> import java.util.concurrent.locks.Lock;
> import java.util.concurrent.locks.ReentrantLock;
> @@ -53,20 +55,24 @@ public class ConcurrentNodeMemories implements NodeMemories {
> public void resetAllMemories(StatefulKnowledgeSession session) {
> InternalKnowledgeBase kBase = (InternalKnowledgeBase)session.getKieBase();
> + Set<SegmentMemory> smems = new HashSet<SegmentMemory>();
> for (int i = 0; i < memories.length(); i++) {
> Memory memory = memories.get(i);
> if (memory != null) {
> if (memory.getSegmentMemory() != null) {
> - SegmentMemory smem = memory.getSegmentMemory();
> - smem.reset(kBase.getSegmentPrototype(smem));
> - if ( smem.isSegmentLinked() ) {
> - smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
> - }
> + smems.add(memory.getSegmentMemory());
> }
> memory.reset();
> }
> }
> +
> + for (SegmentMemory smem : smems) {
> + smem.reset(kBase.getSegmentPrototype(smem));
> + if ( smem.isSegmentLinked() ) {
> + smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
> + }
> + }
> }
> /**
> {code}
> I tried to find out why the order matters here, but apparently lack knowledge here.
> *2. Reset doesn't bring a disposed session back to life*
> With 7.12.0.Final it was possible to bring a disposed session back to life by calling the reset method. In 7.13.0.Final that doesn't work anymore because the checkAlive validation then fails.
> The new session pools seem to deal with that by just setting the alive flag back to true if a session is reused. While the new session pools are great, we would like to stick with our existing and simpler session pooling which makes use of the reset method. So would it be possible to set the alive flag to true on a session reset?
> {code:java}
> diff --git
> a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> index d6f4959e0d..4a6199ad23 100644
> ---
> a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> +++
> b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> @@ -1122,6 +1122,8 @@ public class StatefulKnowledgeSessionImpl extends
> AbstractRuntime
> this.processRuntime = null;
> this.initialFactHandle = initInitialFact(kBase, null);
> +
> + this.alive = true;
> }
> public void reset(int handleId,
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3225) [DMN Designer] Decision table output data type is not stored
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3225?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-3225:
-------------------------------------
[~tari_manga] ok, will try to clarify, with DMN PRs I usually try to use created DMN also in runtime, even if touched code is on client side.
Trying running some DMN decision tables I spotted xml you highlighted in the [comment|https://github.com/kiegroup/drools/pull/2123#pullrequestreview-17...]. As you said in that [comment|https://github.com/kiegroup/drools/pull/2123#pullrequestreview-17...] you will touch code that generates it, so I marked this issue and your [comment|https://github.com/kiegroup/drools/pull/2123#pullrequestreview-17...] as related things.
Not saying you have to fix DROOLS-3225. Anyway I have already approved DROOLS-3225 and filed DROOLS-3227 as corollary. And again, let me clarify, I do not expect you will fix DROOLS-3227, but think during its verification I can spot things related to the [comment|https://github.com/kiegroup/drools/pull/2123#pullrequestreview-17...].
> [DMN Designer] Decision table output data type is not stored
> ------------------------------------------------------------
>
> Key: DROOLS-3225
> URL: https://issues.jboss.org/browse/DROOLS-3225
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Blocker
> Labels: drools-tools
> Attachments: Screenshot from 2018-11-01 10-59-08.png, Screenshot from 2018-11-01 15-31-19.png, job-interview.dmn
>
>
> Issue spotted during DROOLS-3214, however probably not related.
> If decision table output data type is changed, the change is not reflected in the xml.
> Please follow my steps:
> - Create new DMN diagram
> - Add a decision node
> - Set the decision node top level expression as a decision table
> - Double click on Output header cell
> - Select boolean lets say
> - Save the diagram
> Check the source, there will be still stored string output data type, like below:
> {code:xml}
> <dmn:decisionTable id="_DE6CDA18-99D1-4259-9F6D-825209DF7DE8" typeRef="string" hitPolicy="ANY" preferredOrientation="Rule-as-Row">
> <dmn:input id="_EB7B7C02-4131-468C-B1B1-023C39045B66">
> <dmn:inputExpression id="_C72A9C94-130C-4BA5-A529-49BAE217DDFF" typeRef="string">
> <dmn:text>input-1</dmn:text>
> </dmn:inputExpression>
> <dmn:inputValues id="_1EC58DD6-21EB-4822-A333-581363BC325B">
> <dmn:text></dmn:text>
> </dmn:inputValues>
> </dmn:input>
> <dmn:output id="_81248A6E-0239-404A-B891-C7C0BEE6B501" name="output-1" typeRef="string">
> <dmn:outputValues id="_26301186-9EB2-43E8-B6F8-458361E99B45">
> <dmn:text></dmn:text>
> </dmn:outputValues>
> <dmn:defaultOutputEntry id="_EAC89F66-3B9E-4781-B670-1282975F4F1E" typeRef="string">
> <dmn:text></dmn:text>
> </dmn:defaultOutputEntry>
> </dmn:output>
> <dmn:rule id="_EC0CEE6B-E4D5-4DE2-9EE5-86C955933B4E">
> <dmn:inputEntry id="_91AA6110-0A85-4C95-B0B3-D1B084CB0089">
> <dmn:text>"you are right"</dmn:text>
> </dmn:inputEntry>
> <dmn:outputEntry id="_6FACD1CE-8301-413E-8C77-F04AD71B3C78" typeRef="string">
> <dmn:text>true</dmn:text>
> </dmn:outputEntry>
> </dmn:rule>
> </dmn:decisionTable>
> </dmn:decision>
> {code}
> But the UI is like:
> !Screenshot from 2018-11-01 10-59-08.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3228) Rules don't produce the correct result anymore after a session reset
by Christian Liebhardt (Jira)
Christian Liebhardt created DROOLS-3228:
-------------------------------------------
Summary: Rules don't produce the correct result anymore after a session reset
Key: DROOLS-3228
URL: https://issues.jboss.org/browse/DROOLS-3228
Project: Drools
Issue Type: Bug
Affects Versions: 7.13.0.Final
Reporter: Christian Liebhardt
Assignee: Mario Fusco
Hello,
A while ago I've created a test projects to compare the different possibilities of session types and session caching. After an update to Drools 7.13.0.Final I found a performance improvement but also two issues. I would summarize both issues in this ticket as the second one is really minor. Let me know if you have a different preference. Also I'm adding code changes to the ticket description. If you like I can also create a pull request for that. The reason why I hesitated to do this right away is that I'm unclear regarding the solution of the first issue.
1. Incorrect results
If you clone the project and execute [StatefulDroolsEngineUnitTest.java|https://github.com/liebharc/JavaRules/b...] then you will see test failures with 7.13.0.Final while the tests pass with 7.12.0.Final. I could trace the issue back to a recent change in ConcurrentNodeMemories. If I revert this change on a snapshot build of 7.14.0 then the tests pass again. Here the patch for the revert:
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
index 020446190c..48045697af 100644
---
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
+++
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
@@ -16,6 +16,8 @@
package org.drools.core.common;
+import java.util.HashSet;
+import java.util.Set;
import java.util.concurrent.atomic.AtomicReferenceArray;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
@@ -53,20 +55,24 @@ public class ConcurrentNodeMemories implements NodeMemories {
public void resetAllMemories(StatefulKnowledgeSession session) {
InternalKnowledgeBase kBase = (InternalKnowledgeBase)session.getKieBase();
+ Set<SegmentMemory> smems = new HashSet<SegmentMemory>();
for (int i = 0; i < memories.length(); i++) {
Memory memory = memories.get(i);
if (memory != null) {
if (memory.getSegmentMemory() != null) {
- SegmentMemory smem = memory.getSegmentMemory();
- smem.reset(kBase.getSegmentPrototype(smem));
- if ( smem.isSegmentLinked() ) {
- smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
- }
+ smems.add(memory.getSegmentMemory());
}
memory.reset();
}
}
+
+ for (SegmentMemory smem : smems) {
+ smem.reset(kBase.getSegmentPrototype(smem));
+ if ( smem.isSegmentLinked() ) {
+ smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
+ }
+ }
}
/**
{code}
I tried to find out why the order matters here, but apparently lack knowledge here.
2. Reset doesn't bring a disposed session back to life
With 7.12.0.Final it was possible to bring a disposed session back to life by calling the reset method. In 7.13.0.Final that doesn't work anymore because the checkAlive validation then fails.
The new session pools seem to deal with that by just setting the alive flag back to true if a session is reused. While the new session pools are great, we would like to stick with our existing and simpler session pooling which makes use of the reset method. So would it be possible to set the alive flag to true on a session reset?
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
index d6f4959e0d..4a6199ad23 100644
---
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
+++
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
@@ -1122,6 +1122,8 @@ public class StatefulKnowledgeSessionImpl extends
AbstractRuntime
this.processRuntime = null;
this.initialFactHandle = initInitialFact(kBase, null);
+
+ this.alive = true;
}
public void reset(int handleId,
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3228) Rules don't produce the correct result anymore after a session reset
by Christian Liebhardt (Jira)
[ https://issues.jboss.org/browse/DROOLS-3228?page=com.atlassian.jira.plugi... ]
Christian Liebhardt updated DROOLS-3228:
----------------------------------------
Description:
Hello,
A while ago I've created a test projects to compare the different possibilities of session types and session polling/reusing. After an update to Drools 7.13.0.Final I found a performance improvement but also two issues. I would summarize both issues in this ticket as the second one is really minor. Let me know if you have a different preference. Also I'm adding code changes to the ticket description. If you like I can also create a pull request for that. The reason why I hesitated to do this right away is that I'm unclear regarding the solution of the first issue.
1. Incorrect results
If you clone the project and execute [StatefulDroolsEngineUnitTest.java|https://github.com/liebharc/JavaRules/b...] then you will see test failures with 7.13.0.Final while the tests pass with 7.12.0.Final. I could trace the issue back to a recent change in ConcurrentNodeMemories. If I revert this change on a snapshot build of 7.14.0 then the tests pass again. Here the patch for the revert:
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
index 020446190c..48045697af 100644
---
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
+++
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
@@ -16,6 +16,8 @@
package org.drools.core.common;
+import java.util.HashSet;
+import java.util.Set;
import java.util.concurrent.atomic.AtomicReferenceArray;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
@@ -53,20 +55,24 @@ public class ConcurrentNodeMemories implements NodeMemories {
public void resetAllMemories(StatefulKnowledgeSession session) {
InternalKnowledgeBase kBase = (InternalKnowledgeBase)session.getKieBase();
+ Set<SegmentMemory> smems = new HashSet<SegmentMemory>();
for (int i = 0; i < memories.length(); i++) {
Memory memory = memories.get(i);
if (memory != null) {
if (memory.getSegmentMemory() != null) {
- SegmentMemory smem = memory.getSegmentMemory();
- smem.reset(kBase.getSegmentPrototype(smem));
- if ( smem.isSegmentLinked() ) {
- smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
- }
+ smems.add(memory.getSegmentMemory());
}
memory.reset();
}
}
+
+ for (SegmentMemory smem : smems) {
+ smem.reset(kBase.getSegmentPrototype(smem));
+ if ( smem.isSegmentLinked() ) {
+ smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
+ }
+ }
}
/**
{code}
I tried to find out why the order matters here, but apparently lack knowledge here.
2. Reset doesn't bring a disposed session back to life
With 7.12.0.Final it was possible to bring a disposed session back to life by calling the reset method. In 7.13.0.Final that doesn't work anymore because the checkAlive validation then fails.
The new session pools seem to deal with that by just setting the alive flag back to true if a session is reused. While the new session pools are great, we would like to stick with our existing and simpler session pooling which makes use of the reset method. So would it be possible to set the alive flag to true on a session reset?
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
index d6f4959e0d..4a6199ad23 100644
---
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
+++
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
@@ -1122,6 +1122,8 @@ public class StatefulKnowledgeSessionImpl extends
AbstractRuntime
this.processRuntime = null;
this.initialFactHandle = initInitialFact(kBase, null);
+
+ this.alive = true;
}
public void reset(int handleId,
{code}
was:
Hello,
A while ago I've created a test projects to compare the different possibilities of session types and session caching. After an update to Drools 7.13.0.Final I found a performance improvement but also two issues. I would summarize both issues in this ticket as the second one is really minor. Let me know if you have a different preference. Also I'm adding code changes to the ticket description. If you like I can also create a pull request for that. The reason why I hesitated to do this right away is that I'm unclear regarding the solution of the first issue.
1. Incorrect results
If you clone the project and execute [StatefulDroolsEngineUnitTest.java|https://github.com/liebharc/JavaRules/b...] then you will see test failures with 7.13.0.Final while the tests pass with 7.12.0.Final. I could trace the issue back to a recent change in ConcurrentNodeMemories. If I revert this change on a snapshot build of 7.14.0 then the tests pass again. Here the patch for the revert:
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
index 020446190c..48045697af 100644
---
a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
+++
b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
@@ -16,6 +16,8 @@
package org.drools.core.common;
+import java.util.HashSet;
+import java.util.Set;
import java.util.concurrent.atomic.AtomicReferenceArray;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
@@ -53,20 +55,24 @@ public class ConcurrentNodeMemories implements NodeMemories {
public void resetAllMemories(StatefulKnowledgeSession session) {
InternalKnowledgeBase kBase = (InternalKnowledgeBase)session.getKieBase();
+ Set<SegmentMemory> smems = new HashSet<SegmentMemory>();
for (int i = 0; i < memories.length(); i++) {
Memory memory = memories.get(i);
if (memory != null) {
if (memory.getSegmentMemory() != null) {
- SegmentMemory smem = memory.getSegmentMemory();
- smem.reset(kBase.getSegmentPrototype(smem));
- if ( smem.isSegmentLinked() ) {
- smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
- }
+ smems.add(memory.getSegmentMemory());
}
memory.reset();
}
}
+
+ for (SegmentMemory smem : smems) {
+ smem.reset(kBase.getSegmentPrototype(smem));
+ if ( smem.isSegmentLinked() ) {
+ smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
+ }
+ }
}
/**
{code}
I tried to find out why the order matters here, but apparently lack knowledge here.
2. Reset doesn't bring a disposed session back to life
With 7.12.0.Final it was possible to bring a disposed session back to life by calling the reset method. In 7.13.0.Final that doesn't work anymore because the checkAlive validation then fails.
The new session pools seem to deal with that by just setting the alive flag back to true if a session is reused. While the new session pools are great, we would like to stick with our existing and simpler session pooling which makes use of the reset method. So would it be possible to set the alive flag to true on a session reset?
{code:java}
diff --git
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
index d6f4959e0d..4a6199ad23 100644
---
a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
+++
b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
@@ -1122,6 +1122,8 @@ public class StatefulKnowledgeSessionImpl extends
AbstractRuntime
this.processRuntime = null;
this.initialFactHandle = initInitialFact(kBase, null);
+
+ this.alive = true;
}
public void reset(int handleId,
{code}
> Rules don't produce the correct result anymore after a session reset
> --------------------------------------------------------------------
>
> Key: DROOLS-3228
> URL: https://issues.jboss.org/browse/DROOLS-3228
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.13.0.Final
> Reporter: Christian Liebhardt
> Assignee: Mario Fusco
> Priority: Major
>
> Hello,
> A while ago I've created a test projects to compare the different possibilities of session types and session polling/reusing. After an update to Drools 7.13.0.Final I found a performance improvement but also two issues. I would summarize both issues in this ticket as the second one is really minor. Let me know if you have a different preference. Also I'm adding code changes to the ticket description. If you like I can also create a pull request for that. The reason why I hesitated to do this right away is that I'm unclear regarding the solution of the first issue.
> 1. Incorrect results
> If you clone the project and execute [StatefulDroolsEngineUnitTest.java|https://github.com/liebharc/JavaRules/b...] then you will see test failures with 7.13.0.Final while the tests pass with 7.12.0.Final. I could trace the issue back to a recent change in ConcurrentNodeMemories. If I revert this change on a snapshot build of 7.14.0 then the tests pass again. Here the patch for the revert:
> {code:java}
> diff --git
> a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> index 020446190c..48045697af 100644
> ---
> a/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> +++
> b/drools-core/src/main/java/org/drools/core/common/ConcurrentNodeMemories.java
> @@ -16,6 +16,8 @@
> package org.drools.core.common;
> +import java.util.HashSet;
> +import java.util.Set;
> import java.util.concurrent.atomic.AtomicReferenceArray;
> import java.util.concurrent.locks.Lock;
> import java.util.concurrent.locks.ReentrantLock;
> @@ -53,20 +55,24 @@ public class ConcurrentNodeMemories implements NodeMemories {
> public void resetAllMemories(StatefulKnowledgeSession session) {
> InternalKnowledgeBase kBase = (InternalKnowledgeBase)session.getKieBase();
> + Set<SegmentMemory> smems = new HashSet<SegmentMemory>();
> for (int i = 0; i < memories.length(); i++) {
> Memory memory = memories.get(i);
> if (memory != null) {
> if (memory.getSegmentMemory() != null) {
> - SegmentMemory smem = memory.getSegmentMemory();
> - smem.reset(kBase.getSegmentPrototype(smem));
> - if ( smem.isSegmentLinked() ) {
> - smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
> - }
> + smems.add(memory.getSegmentMemory());
> }
> memory.reset();
> }
> }
> +
> + for (SegmentMemory smem : smems) {
> + smem.reset(kBase.getSegmentPrototype(smem));
> + if ( smem.isSegmentLinked() ) {
> + smem.notifyRuleLinkSegment((InternalWorkingMemory)session);
> + }
> + }
> }
> /**
> {code}
> I tried to find out why the order matters here, but apparently lack knowledge here.
> 2. Reset doesn't bring a disposed session back to life
> With 7.12.0.Final it was possible to bring a disposed session back to life by calling the reset method. In 7.13.0.Final that doesn't work anymore because the checkAlive validation then fails.
> The new session pools seem to deal with that by just setting the alive flag back to true if a session is reused. While the new session pools are great, we would like to stick with our existing and simpler session pooling which makes use of the reset method. So would it be possible to set the alive flag to true on a session reset?
> {code:java}
> diff --git
> a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> index d6f4959e0d..4a6199ad23 100644
> ---
> a/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> +++
> b/drools-core/src/main/java/org/drools/core/impl/StatefulKnowledgeSessionImpl.java
> @@ -1122,6 +1122,8 @@ public class StatefulKnowledgeSessionImpl extends
> AbstractRuntime
> this.processRuntime = null;
> this.initialFactHandle = initInitialFact(kBase, null);
> +
> + this.alive = true;
> }
> public void reset(int handleId,
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11271) Deprecation txframework module
by Ondra Chaloupka (Jira)
Ondra Chaloupka created WFLY-11271:
--------------------------------------
Summary: Deprecation txframework module
Key: WFLY-11271
URL: https://issues.jboss.org/browse/WFLY-11271
Project: WildFly
Issue Type: Enhancement
Components: XTS
Reporter: Ondra Chaloupka
Assignee: Ondra Chaloupka
The txframework can be used really for some proof-of-concepts but hardly for production. From that I think as txframework is deprecated in Narayana, not fully integrated in WildFly - recovery does not work, functionality was completely replaced with compensations framework then the txframework is not needed to be maintained as dependency in WildFly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11270) OpenTracing tests are in legacy org.jboss.as package in widlfly-ts-integ-basic
by Michal Jurc (Jira)
Michal Jurc created WFLY-11270:
----------------------------------
Summary: OpenTracing tests are in legacy org.jboss.as package in widlfly-ts-integ-basic
Key: WFLY-11270
URL: https://issues.jboss.org/browse/WFLY-11270
Project: WildFly
Issue Type: Bug
Components: Test Suite
Affects Versions: 14.0.0.Final
Reporter: Michal Jurc
Assignee: Michal Jurc
Currently, all the OpenTracing integration tests are in {{org.jboss.as.test.integration.microprofile.opentracing}} package. They should be moved to {{org.wildfly.test.integration.microprofile.opentracing}} package.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3225) [DMN Designer] Decision table output data type is not stored
by Matteo Mortari (Jira)
[ https://issues.jboss.org/browse/DROOLS-3225?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-3225:
----------------------------------------
[~jomarko]
{quote}I think it is tightly related to this Matteo Mortari's comment{quote}
Sorry, how?
My comment is about the backend engine, in first instance; or with regards to the generated file to suprefluous: inputValues, outputValues, defaultOutputEntry.
However I agree with you as outputEntry and inputEntry typeRef are superfluous in the generated XML file. If the Stunner needs that no problem as long as they are consistent with the input/output clauses, but otherwise typeref in the in/out clauses are the reference.
Hope this clarifies?
> [DMN Designer] Decision table output data type is not stored
> ------------------------------------------------------------
>
> Key: DROOLS-3225
> URL: https://issues.jboss.org/browse/DROOLS-3225
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Blocker
> Labels: drools-tools
> Attachments: Screenshot from 2018-11-01 10-59-08.png, Screenshot from 2018-11-01 15-31-19.png, job-interview.dmn
>
>
> Issue spotted during DROOLS-3214, however probably not related.
> If decision table output data type is changed, the change is not reflected in the xml.
> Please follow my steps:
> - Create new DMN diagram
> - Add a decision node
> - Set the decision node top level expression as a decision table
> - Double click on Output header cell
> - Select boolean lets say
> - Save the diagram
> Check the source, there will be still stored string output data type, like below:
> {code:xml}
> <dmn:decisionTable id="_DE6CDA18-99D1-4259-9F6D-825209DF7DE8" typeRef="string" hitPolicy="ANY" preferredOrientation="Rule-as-Row">
> <dmn:input id="_EB7B7C02-4131-468C-B1B1-023C39045B66">
> <dmn:inputExpression id="_C72A9C94-130C-4BA5-A529-49BAE217DDFF" typeRef="string">
> <dmn:text>input-1</dmn:text>
> </dmn:inputExpression>
> <dmn:inputValues id="_1EC58DD6-21EB-4822-A333-581363BC325B">
> <dmn:text></dmn:text>
> </dmn:inputValues>
> </dmn:input>
> <dmn:output id="_81248A6E-0239-404A-B891-C7C0BEE6B501" name="output-1" typeRef="string">
> <dmn:outputValues id="_26301186-9EB2-43E8-B6F8-458361E99B45">
> <dmn:text></dmn:text>
> </dmn:outputValues>
> <dmn:defaultOutputEntry id="_EAC89F66-3B9E-4781-B670-1282975F4F1E" typeRef="string">
> <dmn:text></dmn:text>
> </dmn:defaultOutputEntry>
> </dmn:output>
> <dmn:rule id="_EC0CEE6B-E4D5-4DE2-9EE5-86C955933B4E">
> <dmn:inputEntry id="_91AA6110-0A85-4C95-B0B3-D1B084CB0089">
> <dmn:text>"you are right"</dmn:text>
> </dmn:inputEntry>
> <dmn:outputEntry id="_6FACD1CE-8301-413E-8C77-F04AD71B3C78" typeRef="string">
> <dmn:text>true</dmn:text>
> </dmn:outputEntry>
> </dmn:rule>
> </dmn:decisionTable>
> </dmn:decision>
> {code}
> But the UI is like:
> !Screenshot from 2018-11-01 10-59-08.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3227) [DMN Designer] Decision table output data type is not stored if decision table is generated according to input data
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3227?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3227:
--------------------------------
Description:
The decision table output column data type is not stored, if the decision table was generated according to some input data.
An example of such table is attached [^auto.dmn] . This table was created in steps below:
- Create new DMN diagram
- Add an Input Data node : *applicant*
- Add a Decision node: *applicant score*
- Connect them
- Define new data type: *tApplicant*.
-- lang:string (Constraints: "c", "java")
-- open source: boolean
- Set *applicant* node data type as *tApplicant*
- Set *applicant score* node data type as *number*
- Open expression editor for *applicant score* node
- Set its top level expression as Decision Table
- Save and download DMN model
- It will be like the attached
{code:xml}
<dmn:output id="_E6C7E5E6-45C5-4FC2-A37B-69806046893F" name="output-1" typeRef="string">
<dmn:outputValues id="_B473BAB4-521D-4FD9-88BC-C28CD497F03A">
<dmn:text></dmn:text>
</dmn:outputValues>
<dmn:defaultOutputEntry id="_85BF133E-380C-4F0E-9E2A-0C5C6493F6B4" typeRef="string">
<dmn:text></dmn:text>
</dmn:defaultOutputEntry>
</dmn:output>
{code}
was:
Issue spotted during DROOLS-3214, however probably not related.
If decision table output data type is changed, the change is not reflected in the xml.
Please follow my steps:
- Create new DMN diagram
- Add a decision node
- Set the decision node top level expression as a decision table
- Double click on Output header cell
- Select boolean lets say
- Save the diagram
Check the source, there will be still stored string output data type, like below:
{code:xml}
<dmn:decisionTable id="_DE6CDA18-99D1-4259-9F6D-825209DF7DE8" typeRef="string" hitPolicy="ANY" preferredOrientation="Rule-as-Row">
<dmn:input id="_EB7B7C02-4131-468C-B1B1-023C39045B66">
<dmn:inputExpression id="_C72A9C94-130C-4BA5-A529-49BAE217DDFF" typeRef="string">
<dmn:text>input-1</dmn:text>
</dmn:inputExpression>
<dmn:inputValues id="_1EC58DD6-21EB-4822-A333-581363BC325B">
<dmn:text></dmn:text>
</dmn:inputValues>
</dmn:input>
<dmn:output id="_81248A6E-0239-404A-B891-C7C0BEE6B501" name="output-1" typeRef="string">
<dmn:outputValues id="_26301186-9EB2-43E8-B6F8-458361E99B45">
<dmn:text></dmn:text>
</dmn:outputValues>
<dmn:defaultOutputEntry id="_EAC89F66-3B9E-4781-B670-1282975F4F1E" typeRef="string">
<dmn:text></dmn:text>
</dmn:defaultOutputEntry>
</dmn:output>
<dmn:rule id="_EC0CEE6B-E4D5-4DE2-9EE5-86C955933B4E">
<dmn:inputEntry id="_91AA6110-0A85-4C95-B0B3-D1B084CB0089">
<dmn:text>"you are right"</dmn:text>
</dmn:inputEntry>
<dmn:outputEntry id="_6FACD1CE-8301-413E-8C77-F04AD71B3C78" typeRef="string">
<dmn:text>true</dmn:text>
</dmn:outputEntry>
</dmn:rule>
</dmn:decisionTable>
</dmn:decision>
{code}
But the UI is like:
!Screenshot from 2018-11-01 10-59-08.png|thumbnail!
> [DMN Designer] Decision table output data type is not stored if decision table is generated according to input data
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-3227
> URL: https://issues.jboss.org/browse/DROOLS-3227
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
> Attachments: auto.dmn
>
>
> The decision table output column data type is not stored, if the decision table was generated according to some input data.
> An example of such table is attached [^auto.dmn] . This table was created in steps below:
> - Create new DMN diagram
> - Add an Input Data node : *applicant*
> - Add a Decision node: *applicant score*
> - Connect them
> - Define new data type: *tApplicant*.
> -- lang:string (Constraints: "c", "java")
> -- open source: boolean
> - Set *applicant* node data type as *tApplicant*
> - Set *applicant score* node data type as *number*
> - Open expression editor for *applicant score* node
> - Set its top level expression as Decision Table
> - Save and download DMN model
> - It will be like the attached
> {code:xml}
> <dmn:output id="_E6C7E5E6-45C5-4FC2-A37B-69806046893F" name="output-1" typeRef="string">
> <dmn:outputValues id="_B473BAB4-521D-4FD9-88BC-C28CD497F03A">
> <dmn:text></dmn:text>
> </dmn:outputValues>
> <dmn:defaultOutputEntry id="_85BF133E-380C-4F0E-9E2A-0C5C6493F6B4" typeRef="string">
> <dmn:text></dmn:text>
> </dmn:defaultOutputEntry>
> </dmn:output>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months