Ernest, I've changed our code to never directly pass a Fact object to two Rete instances. Instead, I'm converting them to strings and pass them in via assertString. I've also eliminated all calls to Fact.setSlotValue().
This seems to have gotten rid of the broken Rete indexes. Thanks a lot for the help. Michael On Thu, Jan 31, 2008 at 12:25:49PM -0500, Ernest Friedman-Hill wrote: > > 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 jess > >instance1 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 - it > becomes 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 you > retract the fact, the Fact object is released and you are free to > alter it as you wish. Alternatively, you can use the method > Rete.modify(jess.Fact, java.lang.String, jess.Value) to modify a fact." > > The reason for this is simple: Jess keeps many different indices over > Fact objects stored in working memory. The indices use the slot data > and/or fact id to order and characterize the facts of each type. If > you change the value of any slot, or the id of a Fact, then one or > more of those indices is going to be invalidated. Try doing the same > thing to a java.util.HashMap sometime: create a class whose hashCode > () depends on the properties of the class, then use instances of that > class as keys in a HashMap; then change the properties of the > objects. Lo and behold, the Map is broken: attempts to find things > based on their keys will fail. That's exactly what's happening here: > the multiple/undead activations are happening because objects aren't > where 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 a > fact-id to a Fact when it is asserted. If you assert the same Fact to > two engines, then the second assert will (almost certainly) assign a > different fact id, and again, the Fact will be misplaced in the first > engine's working memory. Worse, the id might duplicate the id of an > existing 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 is > unfortunately in your application design. You can share definstanced > Java objects between Rete engines, but not Fact objects; it's just > not 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- > >>>case > >>>Jess in demonstrations - any thoughts on how to debug this within > >>>the > >>>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: > >>>PFACT::filemanager-logic-quarantine : f-2777, f-1170, f-2487, > >>>f-3557 > >>>6 17265 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::filemanager-logic-quarantine : f-2777, f-1170, f-2487, > >>>f-3557 > >>>7 17265 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::filemanager-logic-quarantine : f-2777, f-1170, f-2487, > >>>f-3557 > >>>817265 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::filemanager-logic-quarantine : f-2777, f-1170, f-2487, > >>>f-3557 > >>>9 17265 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::filemanager-logic-quarantine : f-2777, f-1170, f-2487, > >>>f-3557 > >>>10 17265 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::filemanager-logic-quarantine : f-2777, f-1170, f-2487, > >>>f-3557 > >>>11 17265 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::filemanager-failure : f-2777, f-1170, f-3557 > >>>12 17265 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::filemanager-failure : f-2777, f-1170, f-3557 > >>>13 17265 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::filemanager-failure : f-2777, f-1170, f-3557 > >>>14 17265 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::filemanager-failure : f-2777, f-1170, f-3557 > >>>15 17265 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::filemanager-failure : f-2777, f-1170, f-3557 > >>>16 17265 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::filemanager-failure : f-2777, f-1170, f-3557 > >>>17 17265 [JessRunner] INFO - --JessSim-- FIRE 1 PFACT::filemanager- > >>>logic-quarantine f-2777, f-1170, f-2487, f-3557 > >>>18 17265 [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") > >>>) > >>>19 17265 [JessRunner] INFO > >>>srs.csism.integration.CsismJessEventHandler - Fact has been > >>>removed with name=WFACT::c_filemanagerReq > >>>20 17266 [i_ilc_service_2046_thread] INFO > >>>srs.csism.integration.IlcJessEventHandler - Fact has been removed > >>>with name=MAIN::dump-all > >>>21 17266 [JessRunner] INFO - --JessSim-- <== Activation: > >>>PFACT::filemanager-failure : f-2777, f-1170, f-3557 > >>>22 17266 [i_ilc_service_2046_thread] INFO > >>>srs.csism.integration.IlcWrapper - # rules fired=4 > >>>23 17266 [JessRunner] WARN srs.csism.jessSim.JunitRouter - !!!! > >>>Quarantine rule: retracting filemanager request <Fact-2777 > >>>24 17266 [JessRunner] INFO - --JessSim-- <=> f-2487 > >>>(WFACT::c_file (idtag i_file_4) (name > >>>"qq_f_combops_usr_afrl_v1_1_clients_combatops_class_server_client_ja > >>>r" > >>>) (has_info ) (has_containers ) (inode 124438) (checkpointWorked > >>>TRUE) (suidp FALSE) (other_permissions i_operation_1873) > >>>(user_permissions i_operation_1873 i_operation_1874) (sgidp FALSE) > >>>(mac_context "system_u:object_r:afrl_t") (filename "/usr/afrl/v1.1/ > >>>clients/CombatOps/class-server/client.jar") (group_permissions > >>>i_operation_1873) (group_owner i_gid_924) (content_keywords ) > >>>(filesystem i_filesystem_25) (user_owner i_uid_1791) (dacl nil) > >>>(quarantineWorked nil) (stickyp FALSE) (integrity_code > >>>"afedcff20abec1c3bf4b775d2a0e7e02")) > >>>25 17266 [JessRunner] INFO > >>>srs.csism.integration.CsismJessEventHandler - Fact has been > >>>modified with name=WFACT::c_file > >>>26 17266 [JessRunner] INFO - --JessSim-- <=> f-2487 > >>>(WFACT::c_file (idtag i_file_4) (name > >>>"qq_f_combops_usr_afrl_v1_1_clients_combatops_class_server_client_ja > >>>r" > >>>) (has_info ) (has_containers ) (inode 124438) (checkpointWorked > >>>TRUE) ( > >>>27 17266 [JessRunner] INFO > >>>srs.csism.integration.CsismJessEventHandler - Fact has been > >>>modified with name=WFACT::c_file > >>>28 17266 [JessRunner] WARN srs.csism.jessSim.JunitRouter - > >>>quarantined file > >>>f_combops_usr_afrl_v1_1_clients_combatops_class_server_client_jar > >>>(i_file_4) on host i_host_84 > >>>29 17266 [JessRunner] INFO - --JessSim-- ==> f-2778 > >>>(WFACT::c_observation (idtag nil) (name nil) (secret FALSE) > >>>(content_keywords ) (viaJ2S FALSE) (t 5.0) (srcSvc > >>>i_filemanager_service_2530) (dstSvc i_ilc_service_2046) (data nil) > >>>(subject > >>>"f_combops_usr_afrl_v1_1_clients_combatops_class_server_client_jar") > >>> ( > >>>releasedToSoar FALSE) (observer i_filemanager_service_2530) (type > >>>quarantineSucceeded) (description nil) (refsFrom nil)) > >>>30 17266 [JessRunner] INFO > >>>srs.csism.integration.CsismJessEventHandler - Fact has been added > >>>with name=WFACT::c_observation > >>>31 17266 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::release-observations : f-2778, f-3557 > >>>32 17266 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::release-observations : f-2778, f-3557 > >>>33 17267 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::release-observations : f-2778, f-3557 > >>>34 17267 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::release-observations : f-2778, f-3557 > >>>35 17267 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::release-observations : f-2778, f-3557 > >>>36 17267 [JessRunner] INFO - --JessSim-- ==> Activation: > >>>PFACT::release-observations : f-2778, f-3557 > >>>37 17267 [JessRunner] INFO - --JessSim-- FIRE 2 PFACT::release- > >>>observations f-2778, f-3557 > >>>38 17267 [JessRunner] INFO - --JessSim-- [t=5.0] - releasing > >>>observation from timecapsule <Fact-2778> > >>>observer=i_filemanager_service_2530 > >>>subject=f_combops_usr_afrl_v1_1_clients_combatops_class_server_clien > >>>t_ > >>>jar type=quarantineSucceeded > >>>39 17267 [JessRunner] INFO - --JessSim-- <=> f-2778 > >>>(WFACT::c_observation (idtag nil) (name nil) (secret FALSE) > >>>(content_keywords ) (viaJ2S FALSE) (t 5.0) (srcSvc > >>>i_filemanager_service_2530) (dstSvc i_ilc_service_2046) (data nil) > >>>(subject > >>>"f_combops_usr_afrl_v1_1_clients_combatops_class_server_client_jar") > >>> ( > >>>releasedToSoar TRUE) (observer i_filemanager_service_2530) (type > >>>quarantineSucceeded) (description nil) (refsFrom nil)) > >>>40 17267 [JessRunner] INFO > >>>srs.csism.integration.CsismJessEventHandler - Fact has been > >>>modified with name=WFACT::c_observation > >>>41 17267 [i_ilc_service_2046_thread] INFO > >>>srs.csism.integration.IlcWrapper - asserting fact > >>>(WFACT::c_observation (idtag nil) (name nil) (secret FALSE) > >>>(content_keywords ) (viaJ2S TRUE) (t 5.0) (srcSvc > >>>i_filemanager_service_2530) (dstSvc i_ilc_service_2046) (data nil) > >>>(subject > >>>"f_combops_usr_afrl_v1_1_clients_combatops_class_server_client_jar") > >>> ( > >>>releasedToSoar TRUE) (observer i_filemanager_service_2530) (type > >>>quarantineSucceeded) (description nil) (refsFrom nil)) into ILC > >>>42 17267 [JessRunner] INFO - --JessSim-- FIRE 3 PFACT::filemanager- > >>>failure f-2777, f-1170, f-3557 > >>>-- > >>>Michael Atighetchi [EMAIL PROTECTED] BBN Technologies > >>> > >>>-------------------------------------------------------------------- > >>>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 owner-jess- > >>>[EMAIL PROTECTED] > >>>-------------------------------------------------------------------- > >> > >>--------------------------------------------------------- > >>Ernest Friedman-Hill > >>Informatics & Decision Sciences Phone: (925) 294-2154 > >>Sandia National Labs FAX: (925) 294-2234 > >>PO Box 969, MS 9012 [EMAIL PROTECTED] > >>Livermore, CA 94550 http://www.jessrules.com > >> > >>-------------------------------------------------------------------- > >>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 owner-jess- > >>[EMAIL PROTECTED] > >>-------------------------------------------------------------------- > > > >-- > >Michael Atighetchi [EMAIL PROTECTED] BBN Technologies > > > >-------------------------------------------------------------------- > >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 owner-jess- > >[EMAIL PROTECTED] > >-------------------------------------------------------------------- > > --------------------------------------------------------- > Ernest Friedman-Hill > Informatics & Decision Sciences Phone: (925) 294-2154 > Sandia National Labs FAX: (925) 294-2234 > PO Box 969, MS 9012 [EMAIL PROTECTED] > Livermore, CA 94550 http://www.jessrules.com > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- -- Michael Atighetchi [EMAIL PROTECTED] BBN Technologies -------------------------------------------------------------------- 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] --------------------------------------------------------------------
