I think I am seeing an
occasional problem with Jess not waking up properly when a Java Bean
changes value.
I am using Jess in a
multi-threaded Java program and connecting the Jess and Java parts of the
program with a handful of Java beans using the dynamic change notification. I
have a deadicated jess thread in my program that calls the Rete engine with
the runUntilHalt command. I have a simple GUI tied into the java beans as a
PropertyChangeListener, so my display sees the same change notices as Jess does.
On overnight runs, I sometimes see the program hang up unexpectedly. The display
shows that the last Java task completed normally and set the Java Bean
properties to show that it had gone idle and Jess should evaluate its results.
Both my display and a save-facts dump with the system in this hung state show
that all the conditions look correct for Jess to fire the evaluation rules and
sechedule another Java task, but the rules did not fire. If I used a GUI button
that asserted a fact to tell jess to change one of my program parameters, the
logjam cleared up and things restarted. Since this fact did interact with my
other rules, I really couldn't convince my self that I wasn't somehow changing
my data to make the dormant rules file.
I finally added a separate
button to assert a totally unrelated fact and added an arbitraty rule to detect
it.
(defrule wake-up "no
interactions with other rules"
?f<-(cattle-prod)
=>
(retract
?f)
(printout t "Woke up" crlf)
)
the button just
called
engine.assertString("(cattle-prod)");
With the system in the
locked up state, asserting the wake fact would print the expected message and
suddenly cause Jess to notice that the conditions of my other scheduling rules
had been met and start firing them. At a minimum, this tells me that the changes
in my beans did actually get delivered to Jess and that I don't have the Jess
thread in some circular deadlock with other parts of my code. I wish I had a
simple test case to demonstrate the problem, but so far I've only seen it in a
large program that typically runs for many hours before hitting on whatever race
condition triggers the problem.
As a temporary work-around,
I can write a trivial Java thread that periodically hits Jess with a
cattle-prod, but that seems ugly, even by my standards.
Does any of this sound
familar? It looks like a Jess bug to me, but I'd be just as happy to find a
fixable problem in my code. Are there any pathological issues with threading and
Jess that I should check for in my code?
