> 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 <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

>     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

Hi Edson,
For a large number of rules comming from decison tables, when arranging them
sometimes it is helpful to modularize tables; with the result of one rule-table
driving another rule table. The preferred method is Decision table. Also this
allows a person to lazy load rules over a set of base rules (part of the reason
is business process and stability around an established concept. The format
makes sense accoring to the business model also) <-- Background, so now i'll
get to the point!

So there is a need of one set of rules (outcome) to influence another (using
tables). Scenario is like this:

Table 1:
-----------
Rule 1.1
Rule 1.2.
Rule 1.3.


Table 2:
----------
Rule 1.2.1 (If fires will influence 1.2)
Rule 1.2.2 (If fires will influence 1.2)

>From this point on, you could suggest anything you see is not fit <----

... Thre preferred way to influence the connection = Change an attribute of the
same object (Since the specific rule in the top table cannot fire till its
conditions are not fullfilled); so when the attribute is set then only the
rules in the above table will become active for that object.

So when the "Business Object" is modified in Table 2, and hence modify() is
called.

You are right, the activation fires and is removed but due to modify() it
causes a re-firing and puts some already fired activation back in the Agenda.

Initally it hung, I realized the reason and put "no-loop". That stopped the
recursion but I noticed certain activationse firing multiple times (Ideally I'd
like the activation to fire and get out but here it would add it back again)
which is not acceptable.

I used "drools.getActivation().remove()" and it stopped the repeats, but then
it was removing subsequent activations as well. I know why now. What I want to
do is prevent this rule from firing again but inturn remove is removing the
next activation. So the question is how to prevent the activation for that
object not to fire again????

My problem ends here (I understand it better now, not sure it should go into
JIRA yet. Would like your comments one more time)

About your comment about removing it. Due to the declrative nature of rules
there are lot of conceptual barriers. So conceptual workarounds are restricted
by the technology so we need every advantage. But then again, if you show me a
better path to a solution I'd be more than happy.

Thanks Edson, Appreciate it!

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev