Wow, Arjun, for the pure sake of finding an eventual bug, your strategy may be acceptable, but for writing rules, using getActivation().remove() is completely invasive to the engine... I have no idea just looking at your example about the effects of doing that... I need to go through the code.
So, may I suggest you open a JIRA with your example for us to investigate the bug? Also, I'm tempted to refactor the interface if possible to not expose the method remove() in the consequence...
What removes does is to remove the activation from the agenda, but the activation already fired, so what's the point of removing it? It may be the case that this is also creating an inconsistent state in the engine, so we need to check if that's the case and not expose the method anymore...
Also, maybe you can show us a more complete example of what you are trying to achieve, so we can advise you on how to do it without calling the activation remove() method.
Thank you for reporting!
Regards,
Edson
2007/6/1, Arjun Dhar <dhar_ar@yahoo.com>:
> This would not happen if I did not use "drools.getActivation().remove(); "
but
> I need to or else rules fire over the same object. But if i use it then a
rule
> gets deactivated without firing.
... Ok I think it's def a bug. I noticed that if i remove the number of
repeats: W
hen I use "drools.getActivation().remove()" the number of activations is
**roughly half**
Well based on the '~statistics~', I'd say that an "getActivation().remove()" is
removing 'two' activations instead of one.
Looking fwd to hear you theory and solution. Statistics are a wonderful thing,
you can misiterpret them as you like.. lol. :o) Ok, please let me know what you
find!
thanks,
Arjun
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com