[JBoss JIRA] (ELY-1663) BC FIPS, Management Interface, ELY04001: No algorithm found matching TLS/SSL protocol selection criteria
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/ELY-1663?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1663:
------------------------------
Priority: Blocker (was: Critical)
> BC FIPS, Management Interface, ELY04001: No algorithm found matching TLS/SSL protocol selection criteria
> --------------------------------------------------------------------------------------------------------
>
> Key: ELY-1663
> URL: https://issues.jboss.org/browse/ELY-1663
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.6.0.Final
> Reporter: Martin Choma
> Priority: Blocker
>
> Rarely 1:30 it happens there occures error accessing http management interface secured with TLS with BC FIPS
> {code}
> Operation {"operation" => "add","address" => [("subsystem" => "elytron"),("server-ssl-context" => "test-server-ssl-context")],"key-manager" => "key-manager-name_test-server-ssl-context","cipher-suite-filter" => "TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256","trust-manager" => "trust-manager-name_test-server-ssl-context","protocols" => ["TLSv1.2"],"need-client-auth" => true} failed: {"outcome" => "failed","failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.test-server-ssl-context" => "java.security.NoSuchAlgorithmException: ELY04001: No algorithm found matching TLS/SSL protocol selection criteria
> Caused by: java.security.NoSuchAlgorithmException: ELY04001: No algorithm found matching TLS/SSL protocol selection criteria"}},"rolled-back" => true}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service org.wildfly.security.ssl-context.test-server-ssl-context: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.test-server-ssl-context: java.security.NoSuchAlgorithmException: ELY04001: No algorithm found matching TLS/SSL protocol selection criteria
> at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:982)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.NoSuchAlgorithmException: ELY04001: No algorithm found matching TLS/SSL protocol selection criteria
> at org.wildfly.security.ssl.SSLUtils.lambda$createSslContextFactory$1(SSLUtils.java:130)
> at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:340)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
> at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:980)
> ... 9 more
> {code}
> Some facts
> * It happens only on management interface BC FIPS TLS tests
> * It does not occur on Undertow secured with BC FIPS
> * Previously there was issue with similar error but that happened everywhere https://issues.jboss.org/browse/ELY-1618
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ELY-1707) Runing tests on JDK11 for branch 1.6.x
by Martin Choma (Jira)
Martin Choma created ELY-1707:
---------------------------------
Summary: Runing tests on JDK11 for branch 1.6.x
Key: ELY-1707
URL: https://issues.jboss.org/browse/ELY-1707
Project: WildFly Elytron
Issue Type: Bug
Components: Testsuite
Affects Versions: 1.6.1.Final
Reporter: Martin Choma
On 1.6.x branch I am having trouble to test with JDK11
{{noformat}}
git checkout 1.6.x
. java_oracle_8.sh
mvn clean test -DskipTests
. java_oracle_11.sh
mvn test -Dmaven.main.skip=true
...
Error occurred during initialization of boot layer
java.lang.module.FindException: Module java.corba not found
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 17.427 s
[INFO] Finished at: 2018-11-05T09:49:17+01:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project wildfly-elytron: ExecutionException The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[ERROR] Command was /bin/sh -c cd /home/mchoma/git-repo/wildfly-elytron && /home/mchoma/app/oracle-jdk-11+28/bin/java -javaagent:/home/mchoma/.m2/repository/org/jmockit/jmockit/1.33/jmockit-1.33.jar --add-modules java.corba,java.sql --illegal-access=permit -Djdk.attach.allowAttachSelf=true -jar /home/mchoma/git-repo/wildfly-elytron/target/surefire/surefirebooter10245887984403962786.jar /home/mchoma/git-repo/wildfly-elytron/target/surefire/surefire10250982648577178380tmp /home/mchoma/git-repo/wildfly-elytron/target/surefire/surefire_04789553250451761755tmp
...
{{noformat}}
Workaround exists. I havet to redefine {noformat}modular.jdk.args{noformat} from
{noformat}<modular.jdk.args>--add-modules java.corba,java.sql --illegal-access=permit</modular.jdk.args>{noformat}
to
{noformat}-Dmodular.jdk.args="--add-modules java.sql --illegal-access=permit"{noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11281) [EAT] : Addition of Mini Lab.
by Panagiotis Sotiropoulos (Jira)
[ https://issues.jboss.org/browse/WFLY-11281?page=com.atlassian.jira.plugin... ]
Panagiotis Sotiropoulos moved JBEAP-15764 to WFLY-11281:
--------------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-11281 (was: JBEAP-15764)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
> [EAT] : Addition of Mini Lab.
> -----------------------------
>
> Key: WFLY-11281
> URL: https://issues.jboss.org/browse/WFLY-11281
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
> Priority: Major
>
> Build an test the servers when all other CIs are down.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 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 project 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 three issues. I would summarize all issues in this ticket, let me know if you have a different preference. I have also created a PR which helped me to continue with my tests: https://github.com/kiegroup/drools/pull/2135
*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.
*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?
*3. A stateless sequential session doesn't execute any rules after a reset*
https://github.com/liebharc/JavaRules/blob/master/src/test/java/com/githu... fails as a stateless sequential session skips all adds to its agenda group queue after the session has been reset.
was:
Hello,
A while ago I've created a test project 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}
> 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 project 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 three issues. I would summarize all issues in this ticket, let me know if you have a different preference. I have also created a PR which helped me to continue with my tests: https://github.com/kiegroup/drools/pull/2135
> *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.
> *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?
> *3. A stateless sequential session doesn't execute any rules after a reset*
> https://github.com/liebharc/JavaRules/blob/master/src/test/java/com/githu... fails as a stateless sequential session skips all adds to its agenda group queue after the session has been reset.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFWIP-135) Bad WARN messages: AMQ222211: Storage is back to stable now...
by Miroslav Novak (Jira)
Miroslav Novak created WFWIP-135:
------------------------------------
Summary: Bad WARN messages: AMQ222211: Storage is back to stable now...
Key: WFWIP-135
URL: https://issues.jboss.org/browse/WFWIP-135
Project: WildFly WIP
Issue Type: Bug
Components: Artemis
Reporter: Miroslav Novak
Assignee: Martyn Taylor
There are unwanted WARN messages:
{code}
13:47:48,158 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 15.0.0.Alpha1-SNAPSHOT (WildFly Core 7.0.0.Alpha4) started in 8017ms - Started 495 of 723 services (489 services are lazy, passive or on-demand)
13:47:50,235 WARN [org.apache.activemq.artemis.core.server] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222183: Blocking message production on address 'jms.queue.InQueue'; size is currently: 10,635,300 bytes; max-size-bytes on address: 10,485,760, global-max-size is 10,635,300
13:47:52,642 WARN [org.apache.activemq.artemis.core.server] (Thread-4 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222211: Storage is back to stable now, under max-disk-usage.
13:47:57,642 WARN [org.apache.activemq.artemis.core.server] (Thread-15 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222211: Storage is back to stable now, under max-disk-usage.
...
{code}
when server has configured {{global-max-memory-size}} and address-full-policy to BLOCK. Once {{global-max-memory-size}} then starts to log above warnings which with max-disk-usage. Which is not correct as no disk limitation was reached.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFWIP-134) Bad WARN messages: AMQ222211: Storage is back to stable now...
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFWIP-134?page=com.atlassian.jira.plugin.... ]
Miroslav Novak updated WFWIP-134:
---------------------------------
Steps to Reproduce:
{code}
git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
cd eap-tests-hornetq/scripts/
git checkout 7a29c18129937a7973b531f5c4f94826841d0985
groovy -DEAP_ZIP_URL=https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messaging-testing-prepare/504/artifact/jboss-eap.zip PrepareServers7.groovy
export WORKSPACE=$PWD
export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap
export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap
export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap
export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap
cd ../jboss-hornetq-testsuite/
mvn clean test -Dtest=GlobalMemoryAndDiskUsageTestCase#testNoStorageWarnLogWhenProducerBlockOnMaxMemorySize -Deap7.org.jboss.qa.hornetq.apps.clients.version=7.1541405981-ehsavoie-WFLY-10326-SNAPSHOT | tee log
{code}
> Bad WARN messages: AMQ222211: Storage is back to stable now...
> --------------------------------------------------------------
>
> Key: WFWIP-134
> URL: https://issues.jboss.org/browse/WFWIP-134
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Major
>
> There are unwanted WARN messages:
> {code}
> 13:47:48,158 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 15.0.0.Alpha1-SNAPSHOT (WildFly Core 7.0.0.Alpha4) started in 8017ms - Started 495 of 723 services (489 services are lazy, passive or on-demand)
> 13:47:50,235 WARN [org.apache.activemq.artemis.core.server] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222183: Blocking message production on address 'jms.queue.InQueue'; size is currently: 10,635,300 bytes; max-size-bytes on address: 10,485,760, global-max-size is 10,635,300
> 13:47:52,642 WARN [org.apache.activemq.artemis.core.server] (Thread-4 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222211: Storage is back to stable now, under max-disk-usage.
> 13:47:57,642 WARN [org.apache.activemq.artemis.core.server] (Thread-15 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222211: Storage is back to stable now, under max-disk-usage.
> ...
> {code}
> when server has configured {{global-max-memory-size}} and address-full-policy to BLOCK. Once {{global-max-memory-size}} then starts to log above warnings which with max-disk-usage. Which is not correct as no disk limitation was reached.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3228) Rules don't produce the correct result anymore after a session reset
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-3228?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-3228:
--------------------------------
Steps to Reproduce: (was:
)
Sprint: 2018 Week 42-44
> 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 project 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, 6 months