November 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-133) wildfly-microprofile-metrics-smallrye_1_0.xsd should provide some documentation for allowed attributes

by Rostislav Svoboda (Jira)

Rostislav Svoboda created WFWIP-133: --------------------------------------- Summary: wildfly-microprofile-metrics-smallrye_1_0.xsd should provide some documentation for allowed attributes Key: WFWIP-133 URL: https://issues.jboss.org/browse/WFWIP-133 Project: WildFly WIP Issue Type: Bug Components: MP Metrics Reporter: Rostislav Svoboda Assignee: Jeff Mesnil wildfly-microprofile-metrics-smallrye_1_0.xsd should provide some documentation for allowed attributes CLI provides description for attributes via {{/subsystem=microprofile-metrics-smallrye:read-resource-description}}. Same information should be present in wildfly-microprofile-metrics-smallrye_1_0.xsd via {{<xs:annotation>}} and {{<xs:documentation>}} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-132) MP Metrics - capabilities names - prefix unification

by Rostislav Svoboda (Jira)

Rostislav Svoboda created WFWIP-132: --------------------------------------- Summary: MP Metrics - capabilities names - prefix unification Key: WFWIP-132 URL: https://issues.jboss.org/browse/WFWIP-132 Project: WildFly WIP Issue Type: Bug Components: MP Metrics Reporter: Rostislav Svoboda Assignee: Jeff Mesnil MP Metrics - capabilities names - prefix unification {{/subsystem=microprofile-metrics-smallrye:read-resource-description}} returns details about capabilities: {code} "capabilities" => [ { "name" => "org.wildfly.extension.microprofile.metrics.smallrye", "dynamic" => false }, { "name" => "org.wildlfy.microprofile.metrics.jmx-registrar", "dynamic" => false }, { "name" => "org.wildlfy.microprofile.metrics.wildfly-registrar", "dynamic" => false } ], {code} Prefix {{org.wildfly.extension.microprofile.metrics}} is used one time, prefix {{org.wildlfy.microprofile.metrics}} is used two times. I think the same prefix could be used for all of them. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3229) DMN compilation of DT with empty inputValues, outputValues, defaultOutputEntry NPEs

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-3229: -------------------------------------- Summary: DMN compilation of DT with empty inputValues, outputValues, defaultOutputEntry NPEs Key: DROOLS-3229 URL: https://issues.jboss.org/browse/DROOLS-3229 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Ought to align to interpreted version. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-131) SmallRye Metrics - MetricsRegistryImpl - removal of entry from map which is currently iterated

by Rostislav Svoboda (Jira)

Rostislav Svoboda created WFWIP-131: --------------------------------------- Summary: SmallRye Metrics - MetricsRegistryImpl - removal of entry from map which is currently iterated Key: WFWIP-131 URL: https://issues.jboss.org/browse/WFWIP-131 Project: WildFly WIP Issue Type: Bug Components: MP Metrics Reporter: Rostislav Svoboda Assignee: Jeff Mesnil SmallRye Metrics - MetricsRegistryImpl - removal of entry from map which is currently iterated https://github.com/smallrye/smallrye-metrics/blob/master/implementation/s... Method {{removeMatching}} is iterating over {{metricMap}}. If there is a match {{remove}} method is called. This method removes entry from {{metricMap}} and from {{metadataMap}}. I don't like the fact that the entry is removed from the map by external method while the map is currently iterated by the {{removeMatching}} method. I think https://docs.oracle.com/javase/8/docs/api/java/util/Iterator.html#remove-- should be called in {{removeMatching}} for {{metricMap}} entry + invocation of metadataMap.remove(entry.getKey()) + log mesasge; -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-130) SmallRye Metrics - JmxWorker - findKeyForValueToBeReplaced could use some polish

by Rostislav Svoboda (Jira)

Rostislav Svoboda created WFWIP-130: --------------------------------------- Summary: SmallRye Metrics - JmxWorker - findKeyForValueToBeReplaced could use some polish Key: WFWIP-130 URL: https://issues.jboss.org/browse/WFWIP-130 Project: WildFly WIP Issue Type: Bug Components: MP Metrics Reporter: Rostislav Svoboda Assignee: Jeff Mesnil SmallRye Metrics - JmxWorker - findKeyForValueToBeReplaced could use some polish https://github.com/smallrye/smallrye-metrics/blob/master/implementation/s... - iterate entrySet instead of keySet - can it happen that there are more entries with value '*' ? - shouldn't the for cycle end when the (first?) match is found ? -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[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, 7 months

1
0
0 / 0

[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, 7 months

1
0
0 / 0

[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, 7 months

1
0
0 / 0

[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, 7 months

1
0
0 / 0

[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, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2018