Hi Sebastian,
Well, I can think of several possible explanations for your
observations. One is that this can happen if you assert a particular
Fact object more than once. Once you assert a Fact from Java, the Rete
engine "owns" that Fact. You can't make any modifications to it and
you can't assert it again, until the Fact is retracted. Once it is
retracted you can reuse it. Perhaps you're doing something along these
lines accidentally. In any case, this will always be a programming
error you can correct.
Another possiblity goes something like this: there are multiple
threads in your application. Between the time that "rule" starts to
fire (in thread-1) and when "mc-top" calls findFactById(), the fact
bound to ?sig is retracted in another thread thread-2. This can lead
to the symptom you describe under Jess 5.1. In Jess 6, you're right,
this can't happen anymore. I have always been aware of the possibility
of this behavior in earlier Jess versions, and I think it's better
than the alternatives (using another mutex to make the rare
concurrency problem go away; my feeling was that this would be a
performance penalty for everyone whether they were affected by this or
not.)
If you want to patch around this in Jess 5, you can add a critical
section around the whole rule-firing sequence that blocks any facts
being modified from other threads. A synchronized(m_facts) { ... }
block in jess/Rete.java from before line to after line 1536 should do
it.
I think Sebastian Varges wrote:
> Hi,
>
> I encountered a problem when using my own Java functions in Jess
> 5.1. Basically, my program has its own agenda of Jess facts and
> asserts them to the Jess KB step by step. Some of these facts are
> clones of other existing facts.
>
> The problem now is that my Java function mc-top sometimes cannot find
> facts by id although exactly these facts have been matched on a rule
> lhs. For example
>
> (defrule rule
> ?sig <- (sign ...)
> =>
> (mc-top ?sig ...))
>
>
> This happens very rarely. In most cases everything works fine so that
> I cannot make any sense out of it. When a fact has already matched on
> a rule lhs, how can it be possible that that very fact cannot be
> located by its id? It may be related to the cloning of Jess facts, but
> on the other hand these clones are added to the Jess KB by a normal
> assert.
>
> Anyway, since fact-ids will disappear in Jess 6x there hope. But where
> should I look at in Jess 5.1?
>
>
> Many thanks for any help
>
> -- Sebastian
>
>
> * ================================ *
> * Sebastian Varges
> * Language Technology Group & ICCS
> * Division of Informatics
> * University of Edinburgh
> * Scotland, UK
> * ================================ *
>
>
>
> -----
>
> This is the mc-top function which is a modification of the Jess modify-code:
>
>
> public class ModifyCopyTop implements Userfunction, Serializable
> {
> public String getName() { return "mc-top"; }
>
> public Value call(ValueVector vv, Context context) throws JessException
> {
> Rete engine = context.getEngine();
> Fact fact;
> int factId = vv.get(1).factIDValue(context);
>
> if ((fact = engine.findFactByID(factId)) == null) // THIS IS WHERE IT GOES
>WRONG ALREADY
> throw new JessException("mc-top", "mc-top: no such fact",
>String.valueOf(factId));
>
> Deftemplate dt = fact.getDeftemplate();
>
> // Making a clone of the existing fact
> Fact fact1 = (Fact) fact.clone();
>
> for (int i= 2; i < vv.size(); i++)
> {
>
> // fetch the slot, value subexp, stored as a List
> ValueVector svp = vv.get(i).listValue(context);
> String slotName = getSlotName(svp, context);
> int idx = dt.getSlotIndex(slotName);
> int type = dt.getSlotType(idx);
>
> // Set the value in the fact
> fact1.setSlotValue(slotName, getSlotValue(svp, context, type));
> }
>
> // and store new fact as single "top"-fact (without actually asserting to KB)
> // Another function takes the stored fact later and asserts it to KB
> engine.store("top",fact1);
>
> return Funcall.TRUE;
> }
> }
>
> ---------------------------------------------------------------------
> 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]
> ---------------------------------------------------------------------
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
