[
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)