wood burning stoves*
The moose likes Other Java Products and Servers and the fly likes Take too long to call reset Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Products » Other Java Products and Servers
Bookmark "Take too long to call reset" Watch "Take too long to call reset" New topic
Author

Take too long to call reset

Hope Zhu
Ranch Hand

Joined: May 11, 2004
Posts: 32
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
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

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.


[Jess in Action][AskingGoodQuestions]
Hope Zhu
Ranch Hand

Joined: May 11, 2004
Posts: 32
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
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

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
Ranch Hand

Joined: May 11, 2004
Posts: 32
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
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

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

Joined: May 11, 2004
Posts: 32
Great! Below is the rule:



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
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Define a JavaBean something like



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



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
Ranch Hand

Joined: May 11, 2004
Posts: 32
Ernest, thank you so much! The problem solved.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Take too long to call reset
 
Similar Threads
Java call backs in XSLT
Multi page form - MDB or SFSB ?
How to add rules to running engine?
Is there any way to convert a shadow fact back to a javabean
imbedding jess in java