[JBoss JIRA] (DROOLS-4413) fireUntilHalt continues to block after session disposed
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4413?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-4413.
---------------------------------
Resolution: Explained
I can reproduce the block with and without the marshaller and indeed the problem is not related to it.
The problem is caused by the fact that often the main thread calls halt on the kiesession before the other tread could call the fireUntilHalt. In other words halt is called on an already inactive session and then has no effect. Subsequently the other thread calls the fireUntilHalt and at that point nobody will halt that firing again causing the firing thread to hang. Adding a sleep before invoking the halt (and thus allow the firing to be called before the halt) solves the problem as demonstrated in the test below.
{code}
@Test(timeout = 10000L)
public void testDisposeAfterMarshall() throws InterruptedException, IOException {
// DROOLS-4413
String str = "package com.sample\n" +
"rule R when\n" +
" $s : String()\n" +
"then\n" +
" System.out.println($s);\n" +
"end\n";
KieBase kbase = new KieHelper().addContent( str, ResourceType.DRL ).build();
KieSession ksession = kbase.newKieSession();
Thread t = new Thread(() -> {
System.out.println("Firing.");
ksession.fireUntilHalt();
System.out.println("Halted.");
});
t.start();
// wait fireUntilHalt to be invoked
Thread.sleep( 100L );
// Halt the session without adding any facts
ksession.halt();
KieMarshallers kMarshallers = KieServices.Factory.get().getMarshallers();
ObjectMarshallingStrategy oms = kMarshallers.newSerializeMarshallingStrategy();
Marshaller marshaller = kMarshallers.newMarshaller( kbase, new ObjectMarshallingStrategy[]{ oms } );
try (ByteArrayOutputStream baos = new ByteArrayOutputStream()) {
marshaller.marshall(baos, ksession);
}
// Destroy
ksession.dispose();
ksession.destroy();
// Wait for our thread to exit
// ** The thread exits if we call t.interrupt();
t.join();
}
{code}
> fireUntilHalt continues to block after session disposed
> -------------------------------------------------------
>
> Key: DROOLS-4413
> URL: https://issues.jboss.org/browse/DROOLS-4413
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.25.0.Final
> Environment: Local build of 7.24.0.Final with Oracle JDK 8
> Reporter: Jesse White
> Assignee: Mario Fusco
> Priority: Major
> Attachments: WhatsWrongWithMeTest.java, halt_log.txt
>
>
> See attached test case that reproduces the problem.
> I'm expecting that a thread calling fireUntilHalt will exit after the session is halted and disposed, but it continues to block. If the code block that performs the marshalling is ignored, then the thread exists as expected.
> Stack is:
> {code:java}
> "Thread-1" #14 daemon prio=5 os_prio=0 tid=0x00007f5a7c683000 nid=0x1c028 in Object.wait() [0x00007f5acc170000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000ecfc67b0> (a org.drools.core.phreak.SynchronizedPropagationList)
> at java.lang.Object.wait(Object.java:502)
> at org.drools.core.phreak.SynchronizedPropagationList.waitOnRest(SynchronizedPropagationList.java:128)
> - locked <0x00000000ecfc67b0> (a org.drools.core.phreak.SynchronizedPropagationList)
> at org.drools.core.common.DefaultAgenda$RestHandler$FireUntilHaltRestHandler.handleRest(DefaultAgenda.java:1133)
> - locked <0x00000000ecfc67b0> (a org.drools.core.phreak.SynchronizedPropagationList)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1074)
> at org.drools.core.common.DefaultAgenda.internalFireUntilHalt(DefaultAgenda.java:991)
> at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:983)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1369)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1348)
> at org.drools.compiler.integrationtests.WhatsWrongWithMeTest.lambda$canReturnWhenHalted$0(WhatsWrongWithMeTest.java:78)
> at org.drools.compiler.integrationtests.WhatsWrongWithMeTest$$Lambda$60/994541328.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFCORE-4571) Value of 'soft-fail' attribute in 'elytron/trust-manager' is not propagated
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFCORE-4571?page=com.atlassian.jira.plugi... ]
Jan Stourac updated WFCORE-4571:
--------------------------------
Security: (was: Red Hat Internal)
> Value of 'soft-fail' attribute in 'elytron/trust-manager' is not propagated
> ---------------------------------------------------------------------------
>
> Key: WFCORE-4571
> URL: https://issues.jboss.org/browse/WFCORE-4571
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Jan Stourac
> Priority: Critical
> Attachments: make-certs.sh
>
>
> Value of the 'soft-fail' attribute that is used in 'trust-manager' resource is not propagated from configuration to server correctly. As such, server always thinks the value is set to 'false'. See steps to reproduce section for more details.
> *NOTE:* I've made this as an internal issue due to the links to our internal GitLab instance mentioned in 'steps to reproduce' section.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFCORE-4571) Value of 'soft-fail' attribute in 'elytron/trust-manager' is not propagated
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFCORE-4571?page=com.atlassian.jira.plugi... ]
Jan Stourac updated WFCORE-4571:
--------------------------------
Description: Value of the 'soft-fail' attribute that is used in 'trust-manager' resource is not propagated from configuration to server correctly. As such, server always thinks the value is set to 'false'. See steps to reproduce section for more details. (was: Value of the 'soft-fail' attribute that is used in 'trust-manager' resource is not propagated from configuration to server correctly. As such, server always thinks the value is set to 'false'. See steps to reproduce section for more details.
*NOTE:* I've made this as an internal issue due to the links to our internal GitLab instance mentioned in 'steps to reproduce' section.)
> Value of 'soft-fail' attribute in 'elytron/trust-manager' is not propagated
> ---------------------------------------------------------------------------
>
> Key: WFCORE-4571
> URL: https://issues.jboss.org/browse/WFCORE-4571
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Jan Stourac
> Priority: Critical
> Attachments: make-certs.sh
>
>
> Value of the 'soft-fail' attribute that is used in 'trust-manager' resource is not propagated from configuration to server correctly. As such, server always thinks the value is set to 'false'. See steps to reproduce section for more details.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months