5:47 a.m.
If you don't have some way of associating the data with a particular Latch it's
easy to get overlap when processing datasets. In general you need some way to group the
data together. You can avoid a back reference to the Latch by having a Set of some sort
in the Latch to which you add all data in the batch. If you use a Set backed by an
IdentityHashMap the overhead is pretty small, and rules look like this:
rule "CountAs"
dialect "java"
salience -1
when
l : Latch()
a : A( this memberOf l.dataSet )
then
retract(a);
l.incACount();
System.out.println("Found an A in " + l);
end
See attached project.
THough I like the cleverness of using the "data in matched objects alters rule
properties" trick, you could have just as easily had a "Latch(value ==
true)" conditional, and that would be more clear, IMO. I'm curious to see of the
enabled trick would perform better, though.
GreG
--- On Sun, 10/3/10, Wolfgang Laun <wolfgang.laun(a)gmail.com> wrote:
From: Wolfgang Laun <wolfgang.laun(a)gmail.com Subject:
Re: [rules-users] fireUntilHalt and timing of rule activations
To: "Rules Users List" <rules-users(a)lists.jboss.org Date: Sunday, October 3, 2010, 4:23 AM
There is another way of associating a Latch object with rules, without having to store a
reference to a Latch in objects:
rule "CountAs"
enabled ( $v )
when
Latch( $v : value )
X( ... )
then ... end
At the beginning, insert Latch( false ), which blocks all rules with this construction, or
modify the Latch object to false before inserting more facts. Then, insert the facts, and,
at the end, modify Latch to true.
Latch latch = new Latch( true );
FactHandle fh = kSession.insert( latch );
kSession.fireAllRules();
latch.setValue( false );
kSession.update( fh, latch );
Of course, you can use multiple Latch objects, adding a name field with a specific value,
so that a latch applies to a subset of rules only:
rule "CountAs"
enabled ( $v )
when
Latch( name == "CountAs", $v : value )
...
But be aware that changes to Latch objects will retrigger rules that have fired
previously; so with this approach you'll have to make sure to retract facts when they
have been processed.
-W
2010/10/3 Greg Barton <greg_barton(a)yahoo.com
Nope, you're not missing anything. What you need is a control object of some sort
thst's inserted after all of the "real" data is inserted. (See attached
project for an example.) Rules will look like this, if the control object is called
BatchLatch and data objects A:
rule "CountAs"
dialect "java"
salience -1
when
l : Latch()
a : A( latch == l )
then
retract(a);
l.incACount();
System.out.println("Found an A in " + bl);
end
Note that the A object being processed is tied back to the latch. This is so multiple
latches can be processed simultaneously and their processing won't be intermingled.
This is necessary because there's no guarantee that two Latch objects aren't in
working memory at once. (Though you could create a rule that enforces this.)
GreG
--- On Sat, 10/2/10, Norman C <rent_my_time(a)yahoo.com> wrote:
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
-----Inline Attachment Follows-----
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
From: Norman C <rent_my_time(a)yahoo.com>
Subject: [rules-users] fireUntilHalt and timing of rule activations
To: rules-users(a)lists.jboss.org
Date: Saturday, October 2, 2010, 10:22 AM
Hi All,
In my app, I have a separate thread calling fireUntilHalt()
continuously. I
have quite a few rules, and I am using salience extensively
to control the order
in which rules are executed. What I have seen (by adding
an event listener) is
that as a new fact is inserted, various rules are
activated. Often, the
fireUntilHalt will start executing fireNextItem in
DefaultAgenda before all of
the activations are complete. So if the rule with the
highest salience
value hasn't been activated at this point, then the first
rule to be fired isn't
the correct one.
This can be worked around by waiting for insert to return
and then calling
fireAllRules(). But it seems like the session should
block fireUntilHalt from
trying to execute activated rules until all activations are
complete. Or am I
missing something here?
thanks,
Norman
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
7:51 a.m.
New subject: fireUntilHalt and timing of rule activations
2010/10/4 Greg Barton <greg_barton(a)yahoo.com>
If you don't have some way of associating the data with a
particular Latch
it's easy to get overlap when processing datasets. In general you need some
way to group the data together. You can avoid a back reference to the Latch
by having a Set of some sort in the Latch to which you add all data in the
batch.
Which burdens all inserts and retracts to be accompanied by correpsonding
updates of the Set/Map.
If you use a Set backed by an IdentityHashMap the overhead is
pretty
small, and rules look like this:
rule "CountAs"
dialect "java"
salience -1
when
l : Latch()
a : A( this memberOf l.dataSet )
then
retract(a);
l.incACount();
System.out.println("Found an A in " + l);
end
See attached project.
THough I like the cleverness of using the "data in matched objects alters
rule properties" trick, you could have just as easily had a "Latch(value ==
true)" conditional, and that would be more clear,
It was meant to emphasize the role of Latch.value as an enabler for the rule
in contrast to a regular constraint being part of the application logic.
YMMV ;-)
IMO. I'm curious to see of the enabled trick would perform
better, though.
Whichever way, there is a considerable burden associated with writing the
rules and, possibly, inserts and retracts. I wonder what the benefits of
having the session run all the time are as opposed to simply let it fire
until it stops; then do the inserts and then fireUntilHalt again? If there
is, I'd opt for the addition of an atomic insertAll(Object... objects) and
then none of this hocus-pocus would be necessary.
-W
GreG
--- On Sun, 10/3/10, Wolfgang Laun <wolfgang.laun(a)gmail.com> wrote:
From: Wolfgang Laun <wolfgang.laun(a)gmail.com>
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
To: "Rules Users List" <rules-users(a)lists.jboss.org>
Date: Sunday, October 3, 2010, 4:23 AM
There is another way of associating a Latch object with rules, without
having to store a reference to a Latch in objects:
rule "CountAs"
enabled ( $v )
when
Latch( $v : value )
X( ... )
then ... end
At the beginning, insert Latch( false ), which blocks all rules with this
construction, or modify the Latch object to false before inserting more
facts. Then, insert the facts, and, at the end, modify Latch to true.
Latch latch = new Latch( true );
FactHandle fh = kSession.insert( latch );
kSession.fireAllRules();
latch.setValue( false );
kSession.update( fh, latch );
Of course, you can use multiple Latch objects, adding a name field with a
specific value, so that a latch applies to a subset of rules only:
rule "CountAs"
enabled ( $v )
when
Latch( name == "CountAs", $v : value )
...
But be aware that changes to Latch objects will retrigger rules that have
fired previously; so with this approach you'll have to make sure to retract
facts when they have been processed.
-W
2010/10/3 Greg Barton <greg_barton(a)yahoo.com>
Nope, you're not missing anything. What you need is a control object of
some sort thst's inserted after all of the "real" data is inserted. (See
attached project for an example.) Rules will look like this, if the control
object is called BatchLatch and data objects A:
rule "CountAs"
dialect "java"
salience -1
when
l : Latch()
a : A( latch == l )
then
retract(a);
l.incACount();
System.out.println("Found an A in " + bl);
end
Note that the A object being processed is tied back to the latch. This is
so multiple latches can be processed simultaneously and their processing
won't be intermingled. This is necessary because there's no guarantee that
two Latch objects aren't in working memory at once. (Though you could create
a rule that enforces this.)
GreG
--- On Sat, 10/2/10, Norman C <rent_my_time(a)yahoo.com> wrote:
> From: Norman C <rent_my_time(a)yahoo.com>
> Subject: [rules-users] fireUntilHalt and timing of rule activations
> To: rules-users(a)lists.jboss.org
> Date: Saturday, October 2, 2010, 10:22 AM
> Hi All,
>
> In my app, I have a separate thread calling fireUntilHalt()
> continuously. I
> have quite a few rules, and I am using salience extensively
> to control the order
>
> in which rules are executed. What I have seen (by adding
> an event listener) is
> that as a new fact is inserted, various rules are
> activated. Often, the
> fireUntilHalt will start executing fireNextItem in
> DefaultAgenda before all of
> the activations are complete. So if the rule with the
> highest salience
> value hasn't been activated at this point, then the first
> rule to be fired isn't
>
> the correct one.
>
> This can be worked around by waiting for insert to return
> and then calling
> fireAllRules(). But it seems like the session should
> block fireUntilHalt from
> trying to execute activated rules until all activations are
> complete. Or am I
> missing something here?
>
> thanks,
> Norman
>
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
-----Inline Attachment Follows-----
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
11:34 p.m.
New subject: fireUntilHalt and timing of rule activations
Thanks for the suggestions. They all look like good ways to handle the
situation I described. However, they require modifying all of the rules to
check for the latch object and its state, which I would prefer not to do and
doesn't seem like would be necessary.
It seems to me that this is something that Drools can handle internally without
the rules having to be written this way. Since the rules engine processes rules
in a single thread, it's a concurrency issue. fireUntilHalt should be blocked
when a fact is inserted/updated/retracted, until all activations as a result of
that change in working memory are completed.
Thoughts?
Norman
________________________________
From: Wolfgang Laun <wolfgang.laun(a)gmail.com To: Rules
Users List <rules-users(a)lists.jboss.org Sent:
Sun, October 3, 2010 10:51:08 PM
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
2010/10/4 Greg Barton <greg_barton(a)yahoo.com
If you don't have some way of associating the data with a particular Latch it's
easy to get overlap when processing datasets. In general you need some way to
group the data together. You can avoid a back reference to the Latch by having
a Set of some sort in the Latch to which you add all data in the batch.
Which burdens all inserts and retracts to be accompanied by correpsonding
updates of the Set/Map.
If you use a Set backed by an IdentityHashMap the overhead is pretty small, and
rules look like this:
Whichever way, there is a considerable burden associated with writing the rules
and, possibly, inserts and retracts. I wonder what the benefits of having the
session run all the time are as opposed to simply let it fire until it stops;
then do the inserts and then fireUntilHalt again? If there is, I'd opt for the
addition of an atomic insertAll(Object... objects) and then none of this
hocus-pocus would be necessary.
-W
>GreG
>--- On Sun, 10/3/10, Wolfgang Laun
<wolfgang.laun(a)gmail.com> wrote:
>From: Wolfgang Laun <wolfgang.laun(a)gmail.com >Subject: Re: [rules-users] fireUntilHalt and timing of rule
activations
>To: "Rules Users List" <rules-users(a)lists.jboss.org >Date: Sunday, October 3, 2010, 4:23 AM
>There is another way of
associating a Latch object with rules, without having to
>store a reference to a Latch in objects:
>rule "CountAs"
>enabled ( $v )
>when
> Latch( $v : value )
> X( ... )
>then ... end
>At the beginning, insert Latch( false ), which blocks all
rules with this
>construction, or modify the Latch object to false before inserting more facts.
>Then, insert the facts, and, at the end, modify Latch to true.
> Latch latch = new Latch(
true );
> FactHandle fh = kSession.insert( latch );
> kSession.fireAllRules();
> latch.setValue( false );
> kSession.update( fh, latch );
>Of course, you can use multiple Latch objects, adding a
name field with a
>specific value, so that a latch applies to a subset of rules only:
>rule "CountAs"
>enabled ( $v )
>when
> Latch( name == "CountAs", $v : value )
> ...
>But be aware that changes to Latch objects will retrigger
rules that have fired
>previously; so with this approach you'll have to make sure to retract facts when
>they have been processed.
>-W
>2010/10/3 Greg Barton
<greg_barton(a)yahoo.com >Nope,
you're not missing anything. What you need is a control object of some
>sort thst's inserted after all of the "real" data is inserted. (See
attached
>project for an example.) Rules will look like this, if the control object is
>called BatchLatch and data objects A:
>rule "CountAs"
> dialect "java"
> salience -1
> when
> l : Latch()
> a : A( latch == l )
> then
> retract(a);
> l.incACount();
> System.out.println("Found an A in
" + bl);
>end
>Note
that the A object being processed is tied back to the latch. This is so
>multiple latches can be processed simultaneously and their processing won't be
>intermingled. This is necessary because there's no guarantee that two Latch
>objects aren't in working memory at once. (Though you could create a rule that
>enforces this.)
>GreG
>---
On Sat, 10/2/10, Norman C <rent_my_time(a)yahoo.com> wrote:
>>
From: Norman C <rent_my_time(a)yahoo.com >> Subject: [rules-users] fireUntilHalt and timing of
rule activations
>> To: rules-users(a)lists.jboss.org
>> Date: Saturday, October 2, 2010, 10:22 AM
>> Hi All,
> >>
In my app, I have a separate thread calling fireUntilHalt()
>> continuously. I
>> have quite a few rules, and I am using salience
extensively
>> to control the order
> >>
in which rules are executed. What I have seen (by adding
>> an event listener) is
>> that as a new fact is inserted, various rules are
>> activated. Often, the
>> fireUntilHalt will start executing fireNextItem in
>> DefaultAgenda before all of
>> the activations are complete. So if the rule with
the
>> highest salience
>> value hasn't been activated at this point, then
the first
>> rule to be fired isn't
> >>
the correct one.
> >>
This can be worked around by waiting for insert to return
>> and then calling
>> fireAllRules(). But it seems like the session should
>> block fireUntilHalt from
>> trying to execute activated rules until all
activations are
>> complete. Or am I
>> missing something here?
> >>
thanks,
>> Norman
> > >>
> > >>
_______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
> >
>_______________________________________________
>rules-users mailing list
>rules-users(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-users
>-----Inline Attachment
Follows-----
>_______________________________________________
>rules-users mailing list
>rules-users(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-users
>
>_______________________________________________
>rules-users mailing list
>rules-users(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-users
rule "CountAs"
dialect "java"
salience -1
when
l : Latch()
a : A( this memberOf l.dataSet )
then
retract(a);
l.incACount();
System.out.println("Found an A in " + l);
end
See attached project.
THough I like the cleverness of using the "data in matched objects alters rule
properties" trick, you could have just as easily had a "Latch(value ==
true)"
conditional, and that would be more clear,
It was meant to emphasize the role of Latch.value as an enabler for the rule in
contrast to a regular constraint being part of the application logic. YMMV ;-)
IMO. I'm curious to see of the enabled trick would perform better, though.
2:27 a.m.
New subject: fireUntilHalt and timing of rule activations
Norman,
What you say makes sense, but it is not implemented. It is
something I think would be good to have. May I suggest you open a JIRA
for it so we track it?
Meanwhile, the workaround I suggest is that instead of using
fireUntilHalt(), you call fireAllRules() in a loop, either after each
X insertions of every Y seconds, depending on your system's
architecture.
Edson
2010/10/5 Norman C <rent_my_time(a)yahoo.com>:
Thanks for the suggestions. They all look like good ways to handle the
situation I described. However, they require modifying all of the rules to
check for the latch object and its state, which I would prefer not to do and
doesn't seem like would be necessary.
It seems to me that this is something that Drools can handle internally
without the rules having to be written this way. Since the rules engine
processes rules in a single thread, it's a concurrency issue. fireUntilHalt
should be blocked when a fact is inserted/updated/retracted, until all
activations as a result of that change in working memory are completed.
Thoughts?
Norman
________________________________
From: Wolfgang Laun <wolfgang.laun(a)gmail.com>
To: Rules Users List <rules-users(a)lists.jboss.org>
Sent: Sun, October 3, 2010 10:51:08 PM
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
2010/10/4 Greg Barton <greg_barton(a)yahoo.com>
>
> If you don't have some way of associating the data with a particular Latch
> it's easy to get overlap when processing datasets. In general you need some
> way to group the data together. You can avoid a back reference to the Latch
> by having a Set of some sort in the Latch to which you add all data in the
> batch.
Which burdens all inserts and retracts to be accompanied by correpsonding
updates of the Set/Map.
>
> If you use a Set backed by an IdentityHashMap the overhead is pretty
> small, and rules look like this:
>
> rule "CountAs"
> dialect "java"
> salience -1
> when
> l : Latch()
> a : A( this memberOf l.dataSet )
> then
> retract(a);
> l.incACount();
> System.out.println("Found an A in " + l);
> end
>
> See attached project.
>
> THough I like the cleverness of using the "data in matched objects alters
> rule properties" trick, you could have just as easily had a "Latch(value
==
> true)" conditional, and that would be more clear,
It was meant to emphasize the role of Latch.value as an enabler for the rule
in contrast to a regular constraint being part of the application logic.
YMMV ;-)
>
> IMO. I'm curious to see of the enabled trick would perform better,
> though.
Whichever way, there is a considerable burden associated with writing the
rules and, possibly, inserts and retracts. I wonder what the benefits of
having the session run all the time are as opposed to simply let it fire
until it stops; then do the inserts and then fireUntilHalt again? If there
is, I'd opt for the addition of an atomic insertAll(Object... objects) and
then none of this hocus-pocus would be necessary.
-W
>
> GreG
>
> --- On Sun, 10/3/10, Wolfgang Laun <wolfgang.laun(a)gmail.com> wrote:
>
> From: Wolfgang Laun <wolfgang.laun(a)gmail.com>
> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
> To: "Rules Users List" <rules-users(a)lists.jboss.org>
> Date: Sunday, October 3, 2010, 4:23 AM
>
> There is another way of associating a Latch object with rules, without
> having to store a reference to a Latch in objects:
>
> rule "CountAs"
> enabled ( $v )
> when
> Latch( $v : value )
> X( ... )
>
> then ... end
>
> At the beginning, insert Latch( false ), which blocks all rules with this
> construction, or modify the Latch object to false before inserting more
> facts. Then, insert the facts, and, at the end, modify Latch to true.
>
>
> Latch latch = new Latch( true );
> FactHandle fh = kSession.insert( latch );
> kSession.fireAllRules();
> latch.setValue( false );
> kSession.update( fh, latch );
>
> Of course, you can use multiple Latch objects, adding a name field with a
> specific value, so that a latch applies to a subset of rules only:
>
>
> rule "CountAs"
>
> enabled ( $v )
>
> when
>
> Latch( name == "CountAs", $v : value )
> ...
>
> But be aware that changes to Latch objects will retrigger rules that have
> fired previously; so with this approach you'll have to make sure to retract
> facts when they have been processed.
>
>
> -W
>
>
> 2010/10/3 Greg Barton <greg_barton(a)yahoo.com>
>
> Nope, you're not missing anything. What you need is a control object of
> some sort thst's inserted after all of the "real" data is inserted.
(See
> attached project for an example.) Rules will look like this, if the control
> object is called BatchLatch and data objects A:
>
>
>
>
> rule "CountAs"
>
> dialect "java"
>
> salience -1
>
> when
>
> l : Latch()
>
> a : A( latch == l )
>
> then
>
> retract(a);
>
> l.incACount();
>
> System.out.println("Found an A in " + bl);
>
> end
>
>
>
> Note that the A object being processed is tied back to the latch. This is
> so multiple latches can be processed simultaneously and their processing
> won't be intermingled. This is necessary because there's no guarantee that
> two Latch objects aren't in working memory at once. (Though you could create
> a rule that enforces this.)
>
>
>
>
> GreG
>
>
>
> --- On Sat, 10/2/10, Norman C <rent_my_time(a)yahoo.com> wrote:
>
>
>
> > From: Norman C <rent_my_time(a)yahoo.com>
>
> > Subject: [rules-users] fireUntilHalt and timing of rule activations
>
> > To: rules-users(a)lists.jboss.org
>
> > Date: Saturday, October 2, 2010, 10:22 AM
>
> > Hi All,
>
> >
>
> > In my app, I have a separate thread calling fireUntilHalt()
>
> > continuously. I
>
> > have quite a few rules, and I am using salience extensively
>
> > to control the order
>
> >
>
> > in which rules are executed. What I have seen (by adding
>
> > an event listener) is
>
> > that as a new fact is inserted, various rules are
>
> > activated. Often, the
>
> > fireUntilHalt will start executing fireNextItem in
>
> > DefaultAgenda before all of
>
> > the activations are complete. So if the rule with the
>
> > highest salience
>
> > value hasn't been activated at this point, then the first
>
> > rule to be fired isn't
>
> >
>
> > the correct one.
>
> >
>
> > This can be worked around by waiting for insert to return
>
> > and then calling
>
> > fireAllRules(). But it seems like the session should
>
> > block fireUntilHalt from
>
> > trying to execute activated rules until all activations are
>
> > complete. Or am I
>
> > missing something here?
>
> >
>
> > thanks,
>
> > Norman
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > rules-users mailing list
>
> > rules-users(a)lists.jboss.org
>
> > https://lists.jboss.org/mailman/listinfo/rules-users
>
> >
>
>
>
>
>
>
> _______________________________________________
>
> rules-users mailing list
>
> rules-users(a)lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
8:34 a.m.
New subject: fireUntilHalt and timing of rule activations
Edson, thanks for the reply. I've logged a ticket:
https://jira.jboss.org/browse/JBRULES-2723
Basically, this is how I'm working around the issue for now.
Thanks,
Norman
----- Original Message ----
From: Edson Tirelli <tirelli(a)post.com>
To: Rules Users List <rules-users(a)lists.jboss.org>
Sent: Tue, October 5, 2010 5:27:58 PM
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
Norman,
What you say makes sense, but it is not implemented. It is
something I think would be good to have. May I suggest you open a JIRA
for it so we track it?
Meanwhile, the workaround I suggest is that instead of using
fireUntilHalt(), you call fireAllRules() in a loop, either after each
X insertions of every Y seconds, depending on your system's
architecture.
Edson
2010/10/5 Norman C <rent_my_time(a)yahoo.com>:
Thanks for the suggestions. They all look like good ways to handle the
situation I described. However, they require modifying all of the rules to
check for the latch object and its state, which I would prefer not to do and
doesn't seem like would be necessary.
It seems to me that this is something that Drools can handle internally
without the rules having to be written this way. Since the rules engine
processes rules in a single thread, it's a concurrency issue. fireUntilHalt
should be blocked when a fact is inserted/updated/retracted, until all
activations as a result of that change in working memory are completed.
Thoughts?
Norman
________________________________
From: Wolfgang Laun <wolfgang.laun(a)gmail.com>
To: Rules Users List <rules-users(a)lists.jboss.org>
Sent: Sun, October 3, 2010 10:51:08 PM
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
2010/10/4 Greg Barton <greg_barton(a)yahoo.com>
>
> If you don't have some way of associating the data with a particular Latch
> it's easy to get overlap when processing datasets. In general you need some
> way to group the data together. You can avoid a back reference to the Latch
> by having a Set of some sort in the Latch to which you add all data in the
> batch.
Which burdens all inserts and retracts to be accompanied by correpsonding
updates of the Set/Map.
>
> If you use a Set backed by an IdentityHashMap the overhead is pretty
> small, and rules look like this:
>
> rule "CountAs"
> dialect "java"
> salience -1
> when
> l : Latch()
> a : A( this memberOf l.dataSet )
> then
> retract(a);
> l.incACount();
> System.out.println("Found an A in " + l);
> end
>
> See attached project.
>
> THough I like the cleverness of using the "data in matched objects alters
> rule properties" trick, you could have just as easily had a "Latch(value
==
> true)" conditional, and that would be more clear,
It was meant to emphasize the role of Latch.value as an enabler for the rule
in contrast to a regular constraint being part of the application logic.
YMMV ;-)
>
> IMO. I'm curious to see of the enabled trick would perform better,
> though.
Whichever way, there is a considerable burden associated with writing the
rules and, possibly, inserts and retracts. I wonder what the benefits of
having the session run all the time are as opposed to simply let it fire
until it stops; then do the inserts and then fireUntilHalt again? If there
is, I'd opt for the addition of an atomic insertAll(Object... objects) and
then none of this hocus-pocus would be necessary.
-W
>
> GreG
>
> --- On Sun, 10/3/10, Wolfgang Laun <wolfgang.laun(a)gmail.com> wrote:
>
> From: Wolfgang Laun <wolfgang.laun(a)gmail.com>
> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
> To: "Rules Users List" <rules-users(a)lists.jboss.org>
> Date: Sunday, October 3, 2010, 4:23 AM
>
> There is another way of associating a Latch object with rules, without
> having to store a reference to a Latch in objects:
>
> rule "CountAs"
> enabled ( $v )
> when
> Latch( $v : value )
> X( ... )
>
> then ... end
>
> At the beginning, insert Latch( false ), which blocks all rules with this
> construction, or modify the Latch object to false before inserting more
> facts. Then, insert the facts, and, at the end, modify Latch to true.
>
>
> Latch latch = new Latch( true );
> FactHandle fh = kSession.insert( latch );
> kSession.fireAllRules();
> latch.setValue( false );
> kSession.update( fh, latch );
>
> Of course, you can use multiple Latch objects, adding a name field with a
> specific value, so that a latch applies to a subset of rules only:
>
>
> rule "CountAs"
>
> enabled ( $v )
>
> when
>
> Latch( name == "CountAs", $v : value )
> ...
>
> But be aware that changes to Latch objects will retrigger rules that have
> fired previously; so with this approach you'll have to make sure to retract
> facts when they have been processed.
>
>
> -W
>
>
> 2010/10/3 Greg Barton <greg_barton(a)yahoo.com>
>
> Nope, you're not missing anything. What you need is a control object of
> some sort thst's inserted after all of the "real" data is inserted.
(See
> attached project for an example.) Rules will look like this, if the control
> object is called BatchLatch and data objects A:
>
>
>
>
> rule "CountAs"
>
> dialect "java"
>
> salience -1
>
> when
>
> l : Latch()
>
> a : A( latch == l )
>
> then
>
> retract(a);
>
> l.incACount();
>
> System.out.println("Found an A in " + bl);
>
> end
>
>
>
> Note that the A object being processed is tied back to the latch. This is
> so multiple latches can be processed simultaneously and their processing
> won't be intermingled. This is necessary because there's no guarantee that
> two Latch objects aren't in working memory at once. (Though you could create
> a rule that enforces this.)
>
>
>
>
> GreG
>
>
>
> --- On Sat, 10/2/10, Norman C <rent_my_time(a)yahoo.com> wrote:
>
>
>
> > From: Norman C <rent_my_time(a)yahoo.com>
>
> > Subject: [rules-users] fireUntilHalt and timing of rule activations
>
> > To: rules-users(a)lists.jboss.org
>
> > Date: Saturday, October 2, 2010, 10:22 AM
>
> > Hi All,
>
> >
>
> > In my app, I have a separate thread calling fireUntilHalt()
>
> > continuously. I
>
> > have quite a few rules, and I am using salience extensively
>
> > to control the order
>
> >
>
> > in which rules are executed. What I have seen (by adding
>
> > an event listener) is
>
> > that as a new fact is inserted, various rules are
>
> > activated. Often, the
>
> > fireUntilHalt will start executing fireNextItem in
>
> > DefaultAgenda before all of
>
> > the activations are complete. So if the rule with the
>
> > highest salience
>
> > value hasn't been activated at this point, then the first
>
> > rule to be fired isn't
>
> >
>
> > the correct one.
>
> >
>
> > This can be worked around by waiting for insert to return
>
> > and then calling
>
> > fireAllRules(). But it seems like the session should
>
> > block fireUntilHalt from
>
> > trying to execute activated rules until all activations are
>
> > complete. Or am I
>
> > missing something here?
>
> >
>
> > thanks,
>
> > Norman
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > rules-users mailing list
>
> > rules-users(a)lists.jboss.org
>
> > https://lists.jboss.org/mailman/listinfo/rules-users
>
> >
>
>
>
>
>
>
> _______________________________________________
>
> rules-users mailing list
>
> rules-users(a)lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
10:15 a.m.
New subject: fireUntilHalt and timing of rule activations
I'd suggest that it may be simple to have a (synchronized) helper method which you
call to insert your objects.
This method would create a batch command containing an insert command and a fireAllRules
command. You only need to fire the rules after you have changed something and this
approach removes all multithread access into the working memory.
Thomas
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-
bounces(a)lists.jboss.org] On Behalf Of Edson Tirelli
Sent: 06 October 2010 01:28
To: Rules Users List
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
Norman,
What you say makes sense, but it is not implemented. It is
something I think would be good to have. May I suggest you open a JIRA
for it so we track it?
Meanwhile, the workaround I suggest is that instead of using
fireUntilHalt(), you call fireAllRules() in a loop, either after each
X insertions of every Y seconds, depending on your system's
architecture.
Edson
2010/10/5 Norman C <rent_my_time(a)yahoo.com>:
>
> Thanks for the suggestions. They all look like good ways to handle the
> situation I described. However, they require modifying all of the rules to
> check for the latch object and its state, which I would prefer not to do and
> doesn't seem like would be necessary.
>
> It seems to me that this is something that Drools can handle internally
> without the rules having to be written this way. Since the rules engine
> processes rules in a single thread, it's a concurrency issue. fireUntilHalt
> should be blocked when a fact is inserted/updated/retracted, until all
> activations as a result of that change in working memory are completed.
>
> Thoughts?
>
>
>
> Norman
>
> ________________________________
> From: Wolfgang Laun <wolfgang.laun(a)gmail.com>
> To: Rules Users List <rules-users(a)lists.jboss.org>
> Sent: Sun, October 3, 2010 10:51:08 PM
> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>
> 2010/10/4 Greg Barton <greg_barton(a)yahoo.com>
>>
>> If you don't have some way of associating the data with a particular Latch
>> it's easy to get overlap when processing datasets. In general you need
some
>> way to group the data together. You can avoid a back reference to the
Latch
>> by having a Set of some sort in the Latch to which you add all data in the
>> batch.
>
> Which burdens all inserts and retracts to be accompanied by correpsonding
> updates of the Set/Map.
>
>>
>> If you use a Set backed by an IdentityHashMap the overhead is pretty
>> small, and rules look like this:
>>
>> rule "CountAs"
>> dialect "java"
>> salience -1
>> when
>> l : Latch()
>> a : A( this memberOf l.dataSet )
>> then
>> retract(a);
>> l.incACount();
>> System.out.println("Found an A in " + l);
>> end
>>
>> See attached project.
>>
>> THough I like the cleverness of using the "data in matched objects alters
>> rule properties" trick, you could have just as easily had a
"Latch(value ==
>> true)" conditional, and that would be more clear,
>
> It was meant to emphasize the role of Latch.value as an enabler for the rule
> in contrast to a regular constraint being part of the application logic.
> YMMV ;-)
>
>
>>
>> IMO. I'm curious to see of the enabled trick would perform better,
>> though.
>
> Whichever way, there is a considerable burden associated with writing the
> rules and, possibly, inserts and retracts. I wonder what the benefits of
> having the session run all the time are as opposed to simply let it fire
> until it stops; then do the inserts and then fireUntilHalt again? If there
> is, I'd opt for the addition of an atomic insertAll(Object... objects) and
> then none of this hocus-pocus would be necessary.
>
> -W
>
>>
>> GreG
>>
>> --- On Sun, 10/3/10, Wolfgang Laun <wolfgang.laun(a)gmail.com> wrote:
>>
>> From: Wolfgang Laun <wolfgang.laun(a)gmail.com>
>> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>> To: "Rules Users List" <rules-users(a)lists.jboss.org>
>> Date: Sunday, October 3, 2010, 4:23 AM
>>
>> There is another way of associating a Latch object with rules, without
>> having to store a reference to a Latch in objects:
>>
>> rule "CountAs"
>> enabled ( $v )
>> when
>> Latch( $v : value )
>> X( ... )
>>
>> then ... end
>>
>> At the beginning, insert Latch( false ), which blocks all rules with this
>> construction, or modify the Latch object to false before inserting more
>> facts. Then, insert the facts, and, at the end, modify Latch to true.
>>
>>
>> Latch latch = new Latch( true );
>> FactHandle fh = kSession.insert( latch );
>> kSession.fireAllRules();
>> latch.setValue( false );
>> kSession.update( fh, latch );
>>
>> Of course, you can use multiple Latch objects, adding a name field with a
>> specific value, so that a latch applies to a subset of rules only:
>>
>>
>> rule "CountAs"
>>
>> enabled ( $v )
>>
>> when
>>
>> Latch( name == "CountAs", $v : value )
>> ...
>>
>> But be aware that changes to Latch objects will retrigger rules that have
>> fired previously; so with this approach you'll have to make sure to retract
>> facts when they have been processed.
>>
>>
>> -W
>>
>>
>> 2010/10/3 Greg Barton <greg_barton(a)yahoo.com>
>>
>> Nope, you're not missing anything. What you need is a control object of
>> some sort thst's inserted after all of the "real" data is
inserted. (See
>> attached project for an example.) Rules will look like this, if the control
>> object is called BatchLatch and data objects A:
>>
>>
>>
>>
>> rule "CountAs"
>>
>> dialect "java"
>>
>> salience -1
>>
>> when
>>
>> l : Latch()
>>
>> a : A( latch == l )
>>
>> then
>>
>> retract(a);
>>
>> l.incACount();
>>
>> System.out.println("Found an A in " + bl);
>>
>> end
>>
>>
>>
>> Note that the A object being processed is tied back to the latch. This is
>> so multiple latches can be processed simultaneously and their processing
>> won't be intermingled. This is necessary because there's no guarantee
that
>> two Latch objects aren't in working memory at once. (Though you could
create
>> a rule that enforces this.)
>>
>>
>>
>>
>> GreG
>>
>>
>>
>> --- On Sat, 10/2/10, Norman C <rent_my_time(a)yahoo.com> wrote:
>>
>>
>>
>> > From: Norman C <rent_my_time(a)yahoo.com>
>>
>> > Subject: [rules-users] fireUntilHalt and timing of rule activations
>>
>> > To: rules-users(a)lists.jboss.org
>>
>> > Date: Saturday, October 2, 2010, 10:22 AM
>>
>> > Hi All,
>>
>> >
>>
>> > In my app, I have a separate thread calling fireUntilHalt()
>>
>> > continuously. I
>>
>> > have quite a few rules, and I am using salience extensively
>>
>> > to control the order
>>
>> >
>>
>> > in which rules are executed. What I have seen (by adding
>>
>> > an event listener) is
>>
>> > that as a new fact is inserted, various rules are
>>
>> > activated. Often, the
>>
>> > fireUntilHalt will start executing fireNextItem in
>>
>> > DefaultAgenda before all of
>>
>> > the activations are complete. So if the rule with the
>>
>> > highest salience
>>
>> > value hasn't been activated at this point, then the first
>>
>> > rule to be fired isn't
>>
>> >
>>
>> > the correct one.
>>
>> >
>>
>> > This can be worked around by waiting for insert to return
>>
>> > and then calling
>>
>> > fireAllRules(). But it seems like the session should
>>
>> > block fireUntilHalt from
>>
>> > trying to execute activated rules until all activations are
>>
>> > complete. Or am I
>>
>> > missing something here?
>>
>> >
>>
>> > thanks,
>>
>> > Norman
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > _______________________________________________
>>
>> > rules-users mailing list
>>
>> > rules-users(a)lists.jboss.org
>>
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>>
>> >
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> rules-users mailing list
>>
>> rules-users(a)lists.jboss.org
>>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>
>>
>>
>> -----Inline Attachment Follows-----
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the postmaster(a)nds.com and delete it from
your system as well as any copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the environment please
do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
8:20 a.m.
New subject: fireUntilHalt and timing of rule activations
Another solution would be to have a simple rule matching an Object
that is a container of facts:
rule "synced bunch insert"
when
$fc : FactContainer( $facts : facts )
then
for( Object $f : $facts ){ insert( $f ); }
retract( $fc );
end
Threads just insert a FactContainer; so this is synced in all ways.
BTW: Having a session run continuously in a thread of its own may be a
necessity if there are timers active; thus just using fireAllRules may
not be a solution in all situations.
-W
On 6 October 2010 10:15, Swindells, Thomas <TSwindells(a)nds.com> wrote:
I'd suggest that it may be simple to have a (synchronized) helper
method which you call to insert your objects.
This method would create a batch command containing an insert command and a fireAllRules
command. You only need to fire the rules after you have changed something and this
approach removes all multithread access into the working memory.
Thomas
> -----Original Message-----
> From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-
> bounces(a)lists.jboss.org] On Behalf Of Edson Tirelli
> Sent: 06 October 2010 01:28
> To: Rules Users List
> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>
> Norman,
>
> What you say makes sense, but it is not implemented. It is
> something I think would be good to have. May I suggest you open a JIRA
> for it so we track it?
>
> Meanwhile, the workaround I suggest is that instead of using
> fireUntilHalt(), you call fireAllRules() in a loop, either after each
> X insertions of every Y seconds, depending on your system's
> architecture.
>
> Edson
>
>
> 2010/10/5 Norman C <rent_my_time(a)yahoo.com>:
> >
> > Thanks for the suggestions. They all look like good ways to handle the
> > situation I described. However, they require modifying all of the rules to
> > check for the latch object and its state, which I would prefer not to do and
> > doesn't seem like would be necessary.
> >
> > It seems to me that this is something that Drools can handle internally
> > without the rules having to be written this way. Since the rules engine
> > processes rules in a single thread, it's a concurrency issue.
fireUntilHalt
> > should be blocked when a fact is inserted/updated/retracted, until all
> > activations as a result of that change in working memory are completed.
> >
> > Thoughts?
> >
> >
> >
> > Norman
> >
> > ________________________________
> > From: Wolfgang Laun <wolfgang.laun(a)gmail.com>
> > To: Rules Users List <rules-users(a)lists.jboss.org>
> > Sent: Sun, October 3, 2010 10:51:08 PM
> > Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
> >
> > 2010/10/4 Greg Barton <greg_barton(a)yahoo.com>
> >>
> >> If you don't have some way of associating the data with a particular
Latch
> >> it's easy to get overlap when processing datasets. In general you need
> some
> >> way to group the data together. You can avoid a back reference to the
> Latch
> >> by having a Set of some sort in the Latch to which you add all data in the
> >> batch.
> >
> > Which burdens all inserts and retracts to be accompanied by correpsonding
> > updates of the Set/Map.
> >
> >>
> >> If you use a Set backed by an IdentityHashMap the overhead is pretty
> >> small, and rules look like this:
> >>
> >> rule "CountAs"
> >> dialect "java"
> >> salience -1
> >> when
> >> l : Latch()
> >> a : A( this memberOf l.dataSet )
> >> then
> >> retract(a);
> >> l.incACount();
> >> System.out.println("Found an A in " + l);
> >> end
> >>
> >> See attached project.
> >>
> >> THough I like the cleverness of using the "data in matched objects
alters
> >> rule properties" trick, you could have just as easily had a
"Latch(value ==
> >> true)" conditional, and that would be more clear,
> >
> > It was meant to emphasize the role of Latch.value as an enabler for the rule
> > in contrast to a regular constraint being part of the application logic.
> > YMMV ;-)
> >
> >
> >>
> >> IMO. I'm curious to see of the enabled trick would perform better,
> >> though.
> >
> > Whichever way, there is a considerable burden associated with writing the
> > rules and, possibly, inserts and retracts. I wonder what the benefits of
> > having the session run all the time are as opposed to simply let it fire
> > until it stops; then do the inserts and then fireUntilHalt again? If there
> > is, I'd opt for the addition of an atomic insertAll(Object... objects) and
> > then none of this hocus-pocus would be necessary.
> >
> > -W
> >
> >>
> >> GreG
> >>
> >> --- On Sun, 10/3/10, Wolfgang Laun <wolfgang.laun(a)gmail.com> wrote:
> >>
> >> From: Wolfgang Laun <wolfgang.laun(a)gmail.com>
> >> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
> >> To: "Rules Users List" <rules-users(a)lists.jboss.org>
> >> Date: Sunday, October 3, 2010, 4:23 AM
> >>
> >> There is another way of associating a Latch object with rules, without
> >> having to store a reference to a Latch in objects:
> >>
> >> rule "CountAs"
> >> enabled ( $v )
> >> when
> >> Latch( $v : value )
> >> X( ... )
> >>
> >> then ... end
> >>
> >> At the beginning, insert Latch( false ), which blocks all rules with this
> >> construction, or modify the Latch object to false before inserting more
> >> facts. Then, insert the facts, and, at the end, modify Latch to true.
> >>
> >>
> >> Latch latch = new Latch( true );
> >> FactHandle fh = kSession.insert( latch );
> >> kSession.fireAllRules();
> >> latch.setValue( false );
> >> kSession.update( fh, latch );
> >>
> >> Of course, you can use multiple Latch objects, adding a name field with a
> >> specific value, so that a latch applies to a subset of rules only:
> >>
> >>
> >> rule "CountAs"
> >>
> >> enabled ( $v )
> >>
> >> when
> >>
> >> Latch( name == "CountAs", $v : value )
> >> ...
> >>
> >> But be aware that changes to Latch objects will retrigger rules that have
> >> fired previously; so with this approach you'll have to make sure to
retract
> >> facts when they have been processed.
> >>
> >>
> >> -W
> >>
> >>
> >> 2010/10/3 Greg Barton <greg_barton(a)yahoo.com>
> >>
> >> Nope, you're not missing anything. What you need is a control object
of
> >> some sort thst's inserted after all of the "real" data is
inserted. (See
> >> attached project for an example.) Rules will look like this, if the control
> >> object is called BatchLatch and data objects A:
> >>
> >>
> >>
> >>
> >> rule "CountAs"
> >>
> >> dialect "java"
> >>
> >> salience -1
> >>
> >> when
> >>
> >> l : Latch()
> >>
> >> a : A( latch == l )
> >>
> >> then
> >>
> >> retract(a);
> >>
> >> l.incACount();
> >>
> >> System.out.println("Found an A in " + bl);
> >>
> >> end
> >>
> >>
> >>
> >> Note that the A object being processed is tied back to the latch. This is
> >> so multiple latches can be processed simultaneously and their processing
> >> won't be intermingled. This is necessary because there's no
guarantee that
> >> two Latch objects aren't in working memory at once. (Though you could
> create
> >> a rule that enforces this.)
> >>
> >>
> >>
> >>
> >> GreG
> >>
> >>
> >>
> >> --- On Sat, 10/2/10, Norman C <rent_my_time(a)yahoo.com> wrote:
> >>
> >>
> >>
> >> > From: Norman C <rent_my_time(a)yahoo.com>
> >>
> >> > Subject: [rules-users] fireUntilHalt and timing of rule activations
> >>
> >> > To: rules-users(a)lists.jboss.org
> >>
> >> > Date: Saturday, October 2, 2010, 10:22 AM
> >>
> >> > Hi All,
> >>
> >> >
> >>
> >> > In my app, I have a separate thread calling fireUntilHalt()
> >>
> >> > continuously. I
> >>
> >> > have quite a few rules, and I am using salience extensively
> >>
> >> > to control the order
> >>
> >> >
> >>
> >> > in which rules are executed. What I have seen (by adding
> >>
> >> > an event listener) is
> >>
> >> > that as a new fact is inserted, various rules are
> >>
> >> > activated. Often, the
> >>
> >> > fireUntilHalt will start executing fireNextItem in
> >>
> >> > DefaultAgenda before all of
> >>
> >> > the activations are complete. So if the rule with the
> >>
> >> > highest salience
> >>
> >> > value hasn't been activated at this point, then the first
> >>
> >> > rule to be fired isn't
> >>
> >> >
> >>
> >> > the correct one.
> >>
> >> >
> >>
> >> > This can be worked around by waiting for insert to return
> >>
> >> > and then calling
> >>
> >> > fireAllRules(). But it seems like the session should
> >>
> >> > block fireUntilHalt from
> >>
> >> > trying to execute activated rules until all activations are
> >>
> >> > complete. Or am I
> >>
> >> > missing something here?
> >>
> >> >
> >>
> >> > thanks,
> >>
> >> > Norman
> >>
> >> >
> >>
> >> >
> >>
> >> >
> >>
> >> >
> >>
> >> >
> >>
> >> > _______________________________________________
> >>
> >> > rules-users mailing list
> >>
> >> > rules-users(a)lists.jboss.org
> >>
> >> > https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >> >
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> rules-users mailing list
> >>
> >> rules-users(a)lists.jboss.org
> >>
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >>
> >>
> >>
> >>
> >> -----Inline Attachment Follows-----
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >
> >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
>
>
> --
> Edson Tirelli
> JBoss Drools Core Development
> JBoss by Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the postmaster(a)nds.com and delete it from
your system as well as any copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the environment please
do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
8:34 a.m.
New subject: fireUntilHalt and timing of rule activations
Norman,
if you create the Jira, please include my suggestion to make this call
accept a collection of facts without any intervening Engine activity.
Thanks
-W
2010/10/5 Norman C <rent_my_time(a)yahoo.com>
Thanks for the suggestions. They all look like good ways to handle the
situation I described. However, they require modifying all of the rules to
check for the latch object and its state, which I would prefer not to do and
doesn't seem like would be necessary.
It seems to me that this is something that Drools can handle internally
without the rules having to be written this way. Since the rules engine
processes rules in a single thread, it's a concurrency issue. fireUntilHalt
should be blocked when a fact is inserted/updated/retracted, until all
activations as a result of that change in working memory are completed.
Thoughts?
Norman
------------------------------
*From:* Wolfgang Laun <wolfgang.laun(a)gmail.com>
*To:* Rules Users List <rules-users(a)lists.jboss.org>
*Sent:* Sun, October 3, 2010 10:51:08 PM
*Subject:* Re: [rules-users] fireUntilHalt and timing of rule activations
2010/10/4 Greg Barton <greg_barton(a)yahoo.com>
> If you don't have some way of associating the data with a particular Latch
> it's easy to get overlap when processing datasets. In general you need some
> way to group the data together. You can avoid a back reference to the Latch
> by having a Set of some sort in the Latch to which you add all data in the
> batch.
Which burdens all inserts and retracts to be accompanied by correpsonding
updates of the Set/Map.
> If you use a Set backed by an IdentityHashMap the overhead is pretty
> small, and rules look like this:
>
> rule "CountAs"
> dialect "java"
> salience -1
> when
> l : Latch()
> a : A( this memberOf l.dataSet )
> then
> retract(a);
> l.incACount();
> System.out.println("Found an A in " + l);
> end
>
> See attached project.
>
> THough I like the cleverness of using the "data in matched objects alters
> rule properties" trick, you could have just as easily had a "Latch(value
==
> true)" conditional, and that would be more clear,
It was meant to emphasize the role of Latch.value as an enabler for the
rule in contrast to a regular constraint being part of the application
logic. YMMV ;-)
> IMO. I'm curious to see of the enabled trick would perform better,
> though.
>
Whichever way, there is a considerable burden associated with writing the
rules and, possibly, inserts and retracts. I wonder what the benefits of
having the session run all the time are as opposed to simply let it fire
until it stops; then do the inserts and then fireUntilHalt again? If there
is, I'd opt for the addition of an atomic insertAll(Object... objects) and
then none of this hocus-pocus would be necessary.
-W
>
> GreG
>
> --- On Sun, 10/3/10, Wolfgang Laun <wolfgang.laun(a)gmail.com> wrote:
>
> From: Wolfgang Laun <wolfgang.laun(a)gmail.com>
> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
> To: "Rules Users List" <rules-users(a)lists.jboss.org>
> Date: Sunday, October 3, 2010, 4:23 AM
>
> There is another way of associating a Latch object with rules, without
> having to store a reference to a Latch in objects:
>
> rule "CountAs"
> enabled ( $v )
> when
> Latch( $v : value )
> X( ... )
>
> then ... end
>
> At the beginning, insert Latch( false ), which blocks all rules with this
> construction, or modify the Latch object to false before inserting more
> facts. Then, insert the facts, and, at the end, modify Latch to true.
>
>
> Latch latch = new Latch( true );
> FactHandle fh = kSession.insert( latch );
> kSession.fireAllRules();
> latch.setValue( false );
> kSession.update( fh, latch );
>
> Of course, you can use multiple Latch objects, adding a name field with a
> specific value, so that a latch applies to a subset of rules only:
>
>
> rule "CountAs"
>
> enabled ( $v )
>
> when
>
> Latch( name == "CountAs", $v : value )
> ...
>
> But be aware that changes to Latch objects will retrigger rules that have
> fired previously; so with this approach you'll have to make sure to retract
> facts when they have been processed.
>
>
> -W
>
>
> 2010/10/3 Greg Barton <greg_barton(a)yahoo.com>
>
> Nope, you're not missing anything. What you need is a control object of
> some sort thst's inserted after all of the "real" data is inserted.
(See
> attached project for an example.) Rules will look like this, if the control
> object is called BatchLatch and data objects A:
>
>
>
>
> rule "CountAs"
>
> dialect "java"
>
> salience -1
>
> when
>
> l : Latch()
>
> a : A( latch == l )
>
> then
>
> retract(a);
>
> l.incACount();
>
> System.out.println("Found an A in " + bl);
>
> end
>
>
>
> Note that the A object being processed is tied back to the latch. This is
> so multiple latches can be processed simultaneously and their processing
> won't be intermingled. This is necessary because there's no guarantee that
> two Latch objects aren't in working memory at once. (Though you could create
> a rule that enforces this.)
>
>
>
>
> GreG
>
>
>
> --- On Sat, 10/2/10, Norman C <rent_my_time(a)yahoo.com> wrote:
>
>
>
> > From: Norman C <rent_my_time(a)yahoo.com>
>
> > Subject: [rules-users] fireUntilHalt and timing of rule activations
>
> > To: rules-users(a)lists.jboss.org
>
> > Date: Saturday, October 2, 2010, 10:22 AM
>
> > Hi All,
>
> >
>
> > In my app, I have a separate thread calling fireUntilHalt()
>
> > continuously. I
>
> > have quite a few rules, and I am using salience extensively
>
> > to control the order
>
> >
>
> > in which rules are executed. What I have seen (by adding
>
> > an event listener) is
>
> > that as a new fact is inserted, various rules are
>
> > activated. Often, the
>
> > fireUntilHalt will start executing fireNextItem in
>
> > DefaultAgenda before all of
>
> > the activations are complete. So if the rule with the
>
> > highest salience
>
> > value hasn't been activated at this point, then the first
>
> > rule to be fired isn't
>
> >
>
> > the correct one.
>
> >
>
> > This can be worked around by waiting for insert to return
>
> > and then calling
>
> > fireAllRules(). But it seems like the session should
>
> > block fireUntilHalt from
>
> > trying to execute activated rules until all activations are
>
> > complete. Or am I
>
> > missing something here?
>
> >
>
> > thanks,
>
> > Norman
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > rules-users mailing list
>
> > rules-users(a)lists.jboss.org
>
> > https://lists.jboss.org/mailman/listinfo/rules-users
>
> >
>
>
>
>
>
>
> _______________________________________________
>
> rules-users mailing list
>
> rules-users(a)lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
8:51 a.m.
New subject: fireUntilHalt and timing of rule activations
Wolfgang, so I don't improperly interpret your suggestion, it may be better if
you add your suggestion to the ticket. This is the ticket I logged:
https://jira.jboss.org/browse/JBRULES-2723
Thanks,
Norman
________________________________
From: Wolfgang Laun <wolfgang.laun(a)gmail.com To: Rules
Users List <rules-users(a)lists.jboss.org Sent:
Tue, October 5, 2010 11:34:53 PM
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
Norman,
if you create the Jira, please include my suggestion to make this call accept a
collection of facts without any intervening Engine activity.
Thanks
-W
2010/10/5 Norman C <rent_my_time(a)yahoo.com
Whichever way, there is a considerable burden associated with writing the rules
and, possibly, inserts and retracts. I wonder what the benefits of having the
session run all the time are as opposed to simply let it fire until it stops;
then do the inserts and then fireUntilHalt again? If there is, I'd opt for the
addition of an atomic insertAll(Object... objects) and then none of this
hocus-pocus would be necessary.
-W
>GreG
>--- On Sun, 10/3/10, Wolfgang Laun
<wolfgang.laun(a)gmail.com> wrote:
>From: Wolfgang Laun <wolfgang.laun(a)gmail.com >Subject: Re: [rules-users] fireUntilHalt and timing of rule
activations
>To: "Rules Users List" <rules-users(a)lists.jboss.org >Date: Sunday, October 3, 2010, 4:23 AM
>There is another way of
associating a Latch object with rules, without having to
>store a reference to a Latch in objects:
>rule "CountAs"
>enabled ( $v )
>when
> Latch( $v : value )
> X( ... )
>then ... end
>At the beginning, insert Latch( false ), which blocks all
rules with this
>construction, or modify the Latch object to false before inserting more facts.
>Then, insert the facts, and, at the end, modify Latch to true.
> Latch latch = new Latch(
true );
> FactHandle fh = kSession.insert( latch );
> kSession.fireAllRules();
> latch.setValue( false );
> kSession.update( fh, latch );
>Of course, you can use multiple Latch objects, adding a
name field with a
>specific value, so that a latch applies to a subset of rules only:
>rule "CountAs"
>enabled ( $v )
>when
> Latch( name == "CountAs", $v : value )
> ...
>But be aware that changes to Latch objects will retrigger
rules that have fired
>previously; so with this approach you'll have to make sure to retract facts when
>they have been processed.
>-W
>2010/10/3 Greg Barton
<greg_barton(a)yahoo.com >Nope,
you're not missing anything. What you need is a control object of some
>sort thst's inserted after all of the "real" data is inserted. (See
attached
>project for an example.) Rules will look like this, if the control object is
>called BatchLatch and data objects A:
>rule "CountAs"
> dialect "java"
> salience -1
> when
> l : Latch()
> a : A( latch == l )
> then
> retract(a);
> l.incACount();
> System.out.println("Found an A in
" + bl);
>end
>Note
that the A object being processed is tied back to the latch. This is so
>multiple latches can be processed simultaneously and their processing won't be
>intermingled. This is necessary because there's no guarantee that two Latch
>objects aren't in working memory at once. (Though you could create a rule that
>enforces this.)
>GreG
>---
On Sat, 10/2/10, Norman C <rent_my_time(a)yahoo.com> wrote:
>>
From: Norman C <rent_my_time(a)yahoo.com >> Subject: [rules-users] fireUntilHalt and timing of
rule activations
>> To: rules-users(a)lists.jboss.org
>> Date: Saturday, October 2, 2010, 10:22 AM
>> Hi All,
> >>
In my app, I have a separate thread calling fireUntilHalt()
>> continuously. I
>> have quite a few rules, and I am using salience
extensively
>> to control the order
> >>
in which rules are executed. What I have seen (by adding
>> an event listener) is
>> that as a new fact is inserted, various rules are
>> activated. Often, the
>> fireUntilHalt will start executing fireNextItem in
>> DefaultAgenda before all of
>> the activations are complete. So if the rule with
the
>> highest salience
>> value hasn't been activated at this point, then
the first
>> rule to be fired isn't
> >>
the correct one.
> >>
This can be worked around by waiting for insert to return
>> and then calling
>> fireAllRules(). But it seems like the session should
>> block fireUntilHalt from
>> trying to execute activated rules until all
activations are
>> complete. Or am I
>> missing something here?
> >>
thanks,
>> Norman
> > >>
> > >>
_______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
> >
>_______________________________________________
>rules-users mailing list
>rules-users(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-users
>-----Inline Attachment
Follows-----
>_______________________________________________
>rules-users mailing list
>rules-users(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-users
>
>_______________________________________________
>rules-users mailing list
>rules-users(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-users
>_______________________________________________
>rules-users mailing list
>rules-users(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-users
Thanks for the suggestions. They all look like good ways to handle the
situation I described. However, they require modifying all of the rules to
check for the latch object and its state, which I would prefer not to do and
doesn't seem like would be necessary.
It seems to me that this is something that Drools can handle internally without
the rules having to be written this way. Since the rules engine processes rules
in a single thread, it's a concurrency issue. fireUntilHalt should be blocked
when a fact is inserted/updated/retracted, until all activations as a result of
that change in working memory are completed.
Thoughts?
Norman
________________________________
From: Wolfgang Laun <wolfgang.laun(a)gmail.com
To: Rules Users List <rules-users(a)lists.jboss.org Sent:
Sun, October 3, 2010 10:51:08 PM
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
2010/10/4 Greg Barton <greg_barton(a)yahoo.com
If you don't have some way of associating the data with a particular Latch it's
easy to get overlap when processing datasets. In general you need some way to
group the data together. You can avoid a back reference to the Latch by having
a Set of some sort in the Latch to which you add all data in the batch.
Which burdens all inserts and retracts to be accompanied by correpsonding
updates of the Set/Map.
If you use a Set backed by an IdentityHashMap the overhead is pretty small, and
rules look like this:
rule "CountAs"
dialect "java"
salience -1
when
l : Latch()
a : A( this memberOf l.dataSet )
then
retract(a);
l.incACount();
System.out.println("Found an A in " + l);
end
See attached project.
THough I like the cleverness of using the "data in matched objects alters rule
properties" trick, you could have just as easily had a "Latch(value ==
true)"
conditional, and that would be more clear,
It was meant to emphasize the role of Latch.value as an enabler for the rule in
contrast to a regular constraint being part of the application logic. YMMV ;-)
IMO. I'm curious to see of the enabled trick would perform better, though.
4959
days inactive
4962
days old
8 comments
5 participants
participants (5)
-
Edson Tirelli -
Greg Barton -
Norman C -
Swindells, Thomas -
Wolfgang Laun