4:22 a.m.
Hi,
I have successfully used UNLOOP to stop repitition of rules in my decision
table when one rule fires when all rules are mutually exclusive...
but I've got two rows/rules matching a condition for a given input, and it
is back to an infinite loop.
Is there something like lock-on-active for a decision table?
My table is basically something like the following, with an update in the
action:
Tariff X Minimum age Maximum Age
1234 5 <blank>
2345 <blank> 30
It checks whether a claim has a tariff, so so if a claim has both tariffs
and is between those two ages, it gets into an infinite update loop.
Thanks,
Daniel
--
View this message in context:
http://n3.nabble.com/infinite-loop-in-decision-table-tp129933p129933.html
Sent from the Drools - User mailing list archive at Nabble.com.
8:45 a.m.
My goal is to get some information out of this thing.
I'm not updating the working memory anymore, and trying to use a global
instead.
and this is really not working at all. It goes through the code, says it is
updating it, then the changes are lost. It doesn't instantiate any new
versions of the global... it just doesn't save. I assume this is because it
needs to be part of working memory, and I have to call update(), right?
But if I call update(), i'm back to square one, with the infinite loop.
--
View this message in context:
http://n3.nabble.com/infinite-loop-in-decision-table-tp129933p130197.html
Sent from the Drools - User mailing list archive at Nabble.com.
3:41 a.m.
The easiest pattern is to create a "GroupLatch" helper object has a name.
Then add two columns, a Condition column which checks that there doesn't exist a Latch
with the given name, and an action column which inserts a new Latch with the given name
into the working memory. If multiple rules have the same name then only one of them will
run (and only once). If they all have different names then you allow all the rules to run
but only once.
Eg:
CONDITION ACTION
NOT GroupLatch
name insert(new GroupLatch("$param"));
Thomas
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-
bounces(a)lists.jboss.org] On Behalf Of djb
Sent: 19 January 2010 10:22
To: rules-users(a)lists.jboss.org
Subject: [rules-users] infinite loop in decision table
Hi,
I have successfully used UNLOOP to stop repitition of rules in my decision
table when one rule fires when all rules are mutually exclusive...
but I've got two rows/rules matching a condition for a given input, and it
is back to an infinite loop.
Is there something like lock-on-active for a decision table?
My table is basically something like the following, with an update in the
action:
Tariff X Minimum age Maximum Age
1234 5 <blank>
2345 <blank> 30
It checks whether a claim has a tariff, so so if a claim has both tariffs
and is between those two ages, it gets into an infinite update loop.
Thanks,
Daniel
--
View this message in context: http://n3.nabble.com/infinite-loop-in-decision-
table-tp129933p129933.html
Sent from the Drools - User mailing list archive at Nabble.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.
An NDS Group Limited company. www.nds.com
3:06 a.m.
Hi Thomas,
I implemented the latch system as you suggested, but came to a problem when
running batches of data.
Since the latch is set when the rule fires, you can't have that rule fire
for more than one piece of data.
So, with this method, for batch processing, you need to include a UUID into
each latch.
Are there any other patterns? All this UUID and Latch/Flag functionality
seems really a lot more complicated than it should be.
I suppose I can write it to only process one piece of data at a time, but
that might end up slower.
Regards,
Daniel
--
View this message in context:
http://n3.nabble.com/infinite-loop-in-decision-table-tp129933p139034.html
Sent from the Drools - User mailing list archive at Nabble.com.
4:12 a.m.
As I see it you have a number of options,
As you have said you could scope your latches so that they only apply to a particular
object, rather than generating a UUID you can probably get away with using the object
reference itself; however you will also need to watch out for memory leaks, this can
probably be solved by having a rule which removes latches when the object they refer to is
no longer in the knowledge base.
You may also be able to use drools flow to fire the pieces in one at a time but not need
to recreate the entire state again.
Your best bet (if possible) is to restructure your model so that your actions don't
modify the objects that your conditions are based upon. For instance rather than actually
performing any changes you populate result objects and use a query after the rules have
finished firing to retrieve them all. This does have the downside however that it removes
one of the advantages of a rules engine that the actions can cause other rules to activate
and deactivate.
Hope this helps, if not hopefully someone else will have some better insights than me,
Thomas
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-
bounces(a)lists.jboss.org] On Behalf Of djb
Sent: 26 January 2010 09:07
To: rules-users(a)lists.jboss.org
Subject: Re: [rules-users] infinite loop in decision table
Hi Thomas,
I implemented the latch system as you suggested, but came to a problem when
running batches of data.
Since the latch is set when the rule fires, you can't have that rule fire
for more than one piece of data.
So, with this method, for batch processing, you need to include a UUID into
each latch.
Are there any other patterns? All this UUID and Latch/Flag functionality
seems really a lot more complicated than it should be.
I suppose I can write it to only process one piece of data at a time, but
that might end up slower.
Regards,
Daniel
--
View this message in context: http://n3.nabble.com/infinite-loop-in-decision-
table-tp129933p139034.html
Sent from the Drools - User mailing list archive at Nabble.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.
An NDS Group Limited company. www.nds.com
5972
days inactive
5979
days old
4 comments
2 participants
participants (2)
-
djb -
Swindells, Thomas