Which version of Jess? It does sound like a race condition where
notifications are getting lost.
I think Steven Goncalo wrote:
> 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?
>
---------------------------------------------------------
Ernest Friedman-Hill
Advanced Software Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
PO Box 969, MS 9012 [EMAIL PROTECTED]
Livermore, CA 94550 http://herzberg.ca.sandia.gov
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify [EMAIL PROTECTED]
--------------------------------------------------------------------
