I think Vicken Kasparian wrote:
>
> Ernest:
>
> Thank you for your reply. The problem I was having was not related to rules
> fire asynchronously but rather rules not firing for some data change events.
> However I found what was causing it. It had to do with the "Thread sleep
> 100" on the RHS of the sleep-if-bored rule. See below.
>
> (deffacts idle-fact
> (idle))
>
> (defrule sleep-if-bored
> (declare (salience -100))
> ?idle <- (idle)
> =>
> (retract ?idle)
> (call java.lang.Thread sleep 100)
> (assert (idle)))
>
> My findings were that if the data change rate in my Java object was faster
> that the thread sleep period in the above rule, then some rules did not get
> fired on data change event.
Sure, that makes sense.
>
> I do not quite understand what is this rule doing, but when I commented out
> the RHS "Thread sleep 100" function call from the sleep-if-bored rule, rules
> started firing for every data change. Can you explain why do I need this
> constant firing of the two rules above, and any repercussion on removing the
> Thread sleep. (would this eat up CPU resources?)
This rule is always on the agenda, at a low priority (low salience.)
This means that if no other rules are activated, then this rule will
fire, putting the engine to sleep for a bit to wait for more
facts. Obviously it's sleeping too long for you. If you take out the
sleep, though, then this rule will fire continuously when no other
rules are active, easting up an awful lot of CPU cycles for nothing.
>
> Write now, I have rete.executeCommand("(run)") executed once in my main
> class. Will it be better if rete.executeCommand("(run 1)") was executed once
> every time the Java code detects a data change?? (Maybe execute it from
> within the methods that change data in my Java objects)
This is one approach. Actually not (run 1), just (run) would be
fine. But in the next release of Jess there will be an even better
approach. I've been doing some work with agents again recently. Agents
need this run-forever behaviour, and I haven't been satisfied with the
idle-rule approach either. So what I've done is used java's wait() and
notify() functions, together with a special semaphore object, to
provide a notification facility. There's a function
waitForActivations() which you can call, either in Java or Jess, which
will pause calling the Thread until a rule becomes active. So instead
of the idle rule, you can write a function like this:
(deffunction run-forever ()
(while TRUE do
(run)
(call (engine) waitForActivations)))
This is the best of both worlds: no wasted CPU time, and instantaneous
response.
> > I think Vicken Kasparian wrote:
> > >
> > > Hello:
> > >
> > > I was doing some tests for a prototype I am working on and found the
> > > following situation.
> > > I have a rule that writes something to screen every time a data changes.
> > > When I create a burst of a high rate data change in a Java object, I am
> > not
> > > getting a rule fire for each data change. That means some data change
> > events
> > > are not triggering rules to fire.
> > >
> > > Is this an expected result or am I doing something wrong??
> > >
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
