Take too long to call reset

[Hope Zhu]

Hi,

In one of my java application I create a jess engine and keep adding shadow facts into the engine. When it starts it runs very fast, and then gets slower and slower. I noticed that the reason was the call to reset engine. I understand that calling reset takes long time when working memory gets too big. But calling reset is the only way I know to get all shadow facts run against rules again, which is what I need. Anybody knows another way to achieve the same goal? Please help.

Thanks in advance

[Ernest Friedman-Hill]

It is during your call to reset() that all the pattern matching is done: each shadow fact is removed, the contents of its slots are refreshed, and it is re-added to working memory. Therefore, you're really asking how to make your rules more efficient. There's some material on this in the manual, and some in the book. The most important guideline is to make the earliest patterns as specific as possible. Important guideline number two is that the "test" conditional element is virtually never necessary -- it's almost always a shorthand for testing directly inside a pattern -- and using it almost always makes rules less efficient. Understand what a "partial match" is, and then concentrate on minimizing the number of partial matches in your rules.

[Hope Zhu]

Ernest, Thanks a lot for your help.

I read your book again about �partial matches�. I am not sure if it�s the cause for my problem. I think I did not explain my problem clear. My application gets messages (shadow facts) and puts them into the working memory continually. On the LHS of the rule I have to use current system time to compare with one of the slot to decide if the rule should be fired. One shadow fact may stay in the working memory for 2 weeks before it can be fired. This is why I have to call reset all the time. Am I using Jess correctly. What's your suggestion?

Thanks again in advance.

[Ernest Friedman-Hill]

Ah. OK.

Represent time as a fact, instead of comparing your messages to the result of an explicit function call. You could have a Bean which fires a property change event once per second on its one property named "time". Then you don't have to call reset at all; just this one fact will be continuously updated.

[Hope Zhu]

I don't know if I get you right. Do you mean I should add a time property in my bean and use it as a dynamical shadow fact? For this to work do I have to keep the bean in my java application memory too? It's hard to do so since I may have max 7 millions shadow facts (same kind of bean) in my working memory at one time. I can not afford to keep both in memory unless both bean & fact ref to the same memory area. This is why I asked before how to get javabean back from a fact. I did try to call "modify" for all facts in the fact-list every time before I call "run". It worked better than calling �reset� but still took a long time. I really don't know what I can try next. Please help.

Thanks

[Ernest Friedman-Hill]

If you show me a typical time-dependent rule, I will show you what to do that might work better.

[Hope Zhu]

Great! Below is the rule:

;function to compare schedule GMT time with current GMT time
;if current GMT time is 2hr before then return TRUE
(deffunction compTime (?x)
  (bind ?nowdate (new Date)) 
  (bind ?offset (float ((call TimeZone getDefault) getOffset (?nowdate getTime))))
  (bind ?gmtTime (long (- (float (?nowdate getTime)) ?offset)))
  (bind ?diff (- (?x getTime) ?gmtTime))
  ;(printout t "diff is : " ?diff crlf)
  ; two hours in diff
  (if (= ?diff 7200000)then
    (return TRUE)
   else
    (return FALSE)))
 
;Rule number one
(defrule RuleOne
?testID <- (fltdata (cancel_x ?x& :( neq (upcase ?x) "X"))
 (alert_Status ?as& :( eq ?as ""))
         (sched_gmt_dt ?t) (est_gmt_dt ?y& :( and (neq ?y nil) (?y after ?t))))
  (test (eq (compTime ?t) TRUE))
  =>
  (printout t "RuleOne fired " ?testID crlf)
  (modify ?testID (alert_Status D))
  (bind ?DBean (fact-slot-value ?testID OBJECT))
  (?*JSMQ* sendToListEmb ?DBean 2) 
  )
 

fltdata is a shadow fact. When I put the fact into the working memory most of the time the current time won�t be exactly 2hrs before sched_gmt_dt. If I don�t do modify or reset at the right time the fact won�t trigger the rule.

Thanks a lot!!
[ November 16, 2004: Message edited by: Ernest Friedman-Hill ]

[Ernest Friedman-Hill]

Define a JavaBean something like

import java.beans.*;
import java.io.Serializable;
 
public class TimeBean implements Serializable {
    public JavaBean() throws JessException {
        m_val = null;
        new Thread() {
          public void run() {
            while (true) {
              try { Thread.sleep(1000); } catch (InterruptedException ie) { return; }
              pcs.firePropertyChange("time", null, null);
            }
          }
        }.start();
    }
 
    public long getTime() {
      // Do your time zone adjustment here; I left it
      // out for clarity.
      return System.currentTimeMillis();
    }
 
    private PropertyChangeSupport pcs = new PropertyChangeSupport(this);
    public void addPropertyChangeListener(PropertyChangeListener pcl) {
      pcs.addPropertyChangeListener(pcl);
    }
    public void removePropertyChangeListener(PropertyChangeListener pcl) {
      pcs.removePropertyChangeListener(pcl);
    }
}

This will fire a PropertyChangeEvent once per second. You could change the sleep interval to be longer or shorter, if you like. Now, create an instance of this and add it to Jess's working memory:

(defclass time TimeBean)
(definstance time (new TimeBean))

Then rewrite your rule something like this (I invite you to write a new deffunction, just for documentation purposes, to make the time comparison expression clearer

(defrule RuleOne
?testID <- (fltdata (cancel_x ?x&  :(  neq (upcase ?x) "X"))
                    (alert_Status "")
    (sched_gmt_dt ?t)
                    (est_gmt_dt ?y&  :(  and (neq ?y nil) (?y after ?t))))
  (time (time ?ct&(= (- ?t ?ct) 720000)))
  =>
  (printout t "RuleOne fired " ?testID crlf)
  (modify ?testID (alert_Status D))
  (bind ?DBean (fact-slot-value ?testID OBJECT))
  (?*JSMQ* sendToListEmb ?DBean 2) )

Now every time the bean ticks, the time comparison will be done -- without your ever needing to reset the engine. Most of the pattern matching will therefore only be done when the bean is added to the engine; only the interesting time comparison will be done more than once. This should be vastly faster.
[ November 17, 2004: Message edited by: Ernest Friedman-Hill ]

[Hope Zhu]

Ernest, thank you so much! The problem solved.