The slot "configurationLocator" in this rule points to a custom Java object we wrote. I have tested all possible return values and error conditions and verified that no exceptions are swallowed. In my development environment every possible scenario causes the rule to assert the fact.
In the production environment the rule fails to assert the fact somewhat regularly. The symptom (rule failing to assert fact) occurs shortly after a JVM is started. Once the JVM comes up in this state it never asserts the fact until restarted. A large portion of the time, maybe > 50% the JVM will come up in a valid state and the rule will assert the fact correctly. This inconsistent behavior is only seen on environments with advanced hardware (quad-processor, dual-core 64-bit linux boxes for example) and is NEVER reproducible on less exotic environments. This has been going on for months now and it is only after great troubleshooting efforts that we have narrowed the issue to this rule not asserting the fact. At this time I am looking at the real possibility of a concurrency issue during initialization of some object state and/or a visibility issue (in the Java Memory Model sense). Both issues could be caused by code which does not hold proper locks when accessing/updating variables. I started looking into the Jess source code (7.0p2) and I have identified at leases one variable which is used in the function call which seems susceptible to both race conditions and thread visibility issues. The variable is a static "s_methods" in the jess.Call class. This variable is accessed exclusively from the static method Call#getMethods(Class). The "getMethods" method does not hold any locks when reading/writing to the HashMap. The "s_methods" variable is not declared "volatile". All these things lead me to believe that writes to the "s_methods" variable are not guaranteed to be visible to other threads and, likewise, a thread reading the "s_methods" variable is not guaranteed to see updates made by other threads. This could happen due to compiler optimizations or aggressive caching at the processor level. Quote from, http://www.ibm.com/developerworks/library/j-jtp03304/, " When a thread exits a synchronized block as part of releasing the associated monitor, the JMM requires that the local processor cache be flushed to main memory...Similarly, as part of acquiring the monitor when entering a synchronized block, local caches are invalidated so that subsequent reads will go directly to main memory and not the local cache. This process guarantees that when a variable is written by one thread during a synchronized block protected by a given monitor and read by another thread during a synchronized block protected by the same monitor, the write to the variable will be visible by the reading thread. The JMM does not make this guarantee in the absence of synchronization -- which is why synchronization (or its younger sibling, volatile) must be used whenever multiple threads are accessing the same variables." I am wondering how much emphasis has been placed on concurrency and visibility issues by the Jess coders? Is there exposure here? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernest Friedman-Hill Sent: Thursday, August 07, 2008 11:14 AM To: jess-users Subject: Re: JESS: Problem in assertion of fact On Aug 7, 2008, at 11:53 AM, Hasan Khan wrote: > What I do not get is why would the config fact not get asserted. > Meaning > what would go wrong in order for this to happen? If the fact already existed (i.e., it was a duplicate of an existing fact) then you wouldn't see an assert event here. Otherwise, unless you've got some Java code that's swallowing an exception without reporting it, then I don't think there's any other way for this to happen. --------------------------------------------------------- Ernest Friedman-Hill Informatics & Decision Sciences, Sandia National Laboratories PO Box 969, MS 9012, 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] -------------------------------------------------------------------- Confidentiality Notice: ********************************************** This E-mail and any attachments thereto, are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this E-mail, you are hereby notified any dissemination, distribution or copying of this E-mail, and any attachments thereto, is strictly prohibited. If you receive this E-mail in error, please immediately notify me by reply E-mail or telephone at (218) 723-7887 and permanently delete the original and any copy of this E-mail, and any printout thereof. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
