Re: JESS: bug in rule execution semantics

Ernest Friedman-Hill Thu, 31 Jan 2008 09:28:27 -0800


On Jan 31, 2008, at 11:59 AM, Michael Atighetchi wrote:

Ernest,

thanks for the quick reply.

On Thu, Jan 31, 2008 at 11:23:00AM -0500, Ernest Friedman-Hill wrote:

These are the kinds of problems you can see if the Rete network
indexes are getting broken because of "surprise" fact changes. This
can happen, for example, if jess.Fact objects are getting modified
other than by "modify" calls, or if a single jess.Fact is being
asserted to more than one engine at once. Is it possible that
anything like this is happening?

We have an event listener that processes new facts added to jessinstance1 and

make calls like

Fact f
f.setSlotValue(Slots.viaJ2S, Funcall.TRUE);

before passing f on to jess instance2. So, clearly there is an API for
modifying facts other than through modify.


Indeed, but this is from the top of the Javadoc page for jess.Fact:

"Once you assert a jess.Fact object, you no longer "own" it - itbecomes part of the Rete object's internal data structures. As such,you must not change the values of any of the Fact's slots. If youretract the fact, the Fact object is released and you are free toalter it as you wish. Alternatively, you can use the methodRete.modify(jess.Fact, java.lang.String, jess.Value) to modify a fact."

The reason for this is simple: Jess keeps many different indices overFact objects stored in working memory. The indices use the slot dataand/or fact id to order and characterize the facts of each type. Ifyou change the value of any slot, or the id of a Fact, then one ormore of those indices is going to be invalidated. Try doing the samething to a java.util.HashMap sometime: create a class whose hashCode() depends on the properties of the class, then use instances of thatclass as keys in a HashMap; then change the properties of theobjects. Lo and behold, the Map is broken: attempts to find thingsbased on their keys will fail. That's exactly what's happening here:the multiple/undead activations are happening because objects aren'twhere Jess expects them to be.


Also, I assumed that Rete() instances are indepedent of each other, so
asserting a fact to both engines should be ok.

Nope. Even if you don't change the slot values, ever, Jess assigns afact-id to a Fact when it is asserted. If you assert the same Fact totwo engines, then the second assert will (almost certainly) assign adifferent fact id, and again, the Fact will be misplaced in the firstengine's working memory. Worse, the id might duplicate the id of anexisting fact in the first engine.


We are looking at giving you the self-contained version you mentioned,
though this may induce significant delays due to legal and license
issues.

Is there anything we can do on our end to do a more detailed debugging
of the Rete engine to find out where the corruption starts ?  As
mentioned, we can also give you detailed traces (if that helps).

This isn't necessary; we're all done debugging. The problem isunfortunately in your application design. You can share definstancedJava objects between Rete engines, but not Fact objects; it's justnot allowed.


On Jan 31, 2008, at 10:55 AM, Michael Atighetchi wrote:

I'm starting this under a new thread, since I'm not sure whether it
is realted
to the multiple activation problem reported earlier

http://www.mail-archive.com/[email protected]/msg09948.html

After running jess for a while (hundred rule firings or so), we
start noticing
situations in which two rules get activated, one fires and retracts
a fact that
caused the original activation, but then the second rule fires
regardless. It is
my understanding that retracting a fact that caused a rule
activation should prevent
that rule from firing.

Below  is the relevant excerpt of the trace:
Note that fact f-2777 gets retracted on line (18) but then the same
f-2777 triggers firing
of a rule on line (42). Note that the values in [] are the thread
names running jess, and we
actually have two jess instances running independent of each other
with dedicated thread
(JessRunner and i_ilc_service_2046_thread).

I'm using the latest available version 71b1.

We are approaching an important project deadline and want to show-caseJess in demonstrations - any thoughts on how to debug this withinthe

next day or two ? Let me know if you want the full execution trace,
and I'd be happy to send it to folks.

Michael


---
1 17264 [JessRunner] INFO - --JessSim--   ==> Focus PFACT
2 17264 [JessRunner] INFO - --JessSim--   ==> f-2777
(WFACT::c_filemanagerReq (idtag nil) (name nil) (secret FALSE)
(content_keywords ) (viaJ2S TRUE) (t 0.0) (srcSvc
i_ilc_service_2046) (dstSvc i_filemanager_service_2530) (action
quarantine) (tag SUSPECT) (filename

"f_combops_usr_afrl_v1_1_clients_combatops_class_server_client_jar"))

3 17264 [JessRunner] INFO
srs.csism.integration.CsismJessEventHandler  - Fact has been added
with name=WFACT::c_filemanagerReq
4 17264 [JessRunner] INFO
srs.csism.integration.CsismJessEventHandler  - Lookin at
name=WFACT::c_filemanagerReq
5 17265 [JessRunner] INFO - --JessSim--  ==> Activation: