I had a similar problem and I think it has to do with the fact that
you declare in the drl that service is a HashMap but in the Java class
it is a HashMap. I could be wrong, but you might
try making them match. I think that's what worked for me, if my
memory serves me correctly.
Sara
On Mon, Ju
A small update. I ran the example below starting with 90 rules and running
down to 1. The execution time remains the same so I don't think the problem
has to do with something left over from the previous call to fireAllRules().
This really should be a simple example and I am still at a loss
Hi,
this is a repost, and I'm sorry if I annoy anybody with it, but it's
already a week and nobody replied yet (to what I think might be a
serious issue for anybody using XML for configuration).
Or might this be an issue for the developers list rather than this list
and should i post it there?
I'm in IRC now.
The non-business sensitive test case hasn't been maintained. At this
stage it might be pretty difficult to create one that doesn't have
proprietary information and still functions anywhere the same. We've
got nearly 200 rules and 20 different kinds of facts. I wonder if a
simple
Eric-
Mark has my test code and said he'll look at it in a few days. I'm sure he'll
reply here but if not, I'll post it. My question for you is how quickly does
fireAllRules() run for you? As I said, with only 95 facts loaded it is taking
my machine (dual core 2 GHz box, Fedora Core 6) almo
Fenderbosch, Eric wrote:
We are having a similar problem, although our fact count is much higher.
Performance seems pretty good and consistent until about 400k facts,
then performance degrades significantly. Part of the degradation is
from bigger and more frequent GCs, but not all of it.
If y
Hello,
I get this exception: Exception in thread "main" java.lang.RuntimeException:
Unexpected global [service]
That's the global declaration in the drl: global java.util.HashMap service
And ther I set teh global in teh Java-class:
HashMap service = new HashMap();
workingMemory.setGlobal("servi
We are having a similar problem, although our fact count is much higher.
Performance seems pretty good and consistent until about 400k facts,
then performance degrades significantly. Part of the degradation is
from bigger and more frequent GCs, but not all of it.
Time to load first 100k facts: ~1
I forgot the updates and added a couple of $'s (see below).
Scott Reed wrote:
1) Finding all the duplicate pairs is causing combinatorial explosion.
With 3 objects the rule will compare every object against every
other object which requires running the run about 450 MILLION times.
If you m
1) Finding all the duplicate pairs is causing combinatorial explosion.
With 3 objects the rule will compare every object against every
other object which requires running the run about 450 MILLION times. If
you must discover every pair that is a duplicate, then I think you have
a hard probl
Hi,
Which is the quantity of rules that can be loaded without harming the
performance.
Rules can be loaded under demand?
Thank you
--
View this message in context:
http://www.nabble.com/Quantity-of-rules-that-can-be-loaded-tp18194659p18194659.html
Sent from the drools - user mailing list ar
Hi All
I am new to drools and I am trying to see if we can use it. I have a simple
file
public class Data {
private int id =0;
public Data(int id) {
this.id = id;
}
public int getId() {
return id;
}
}
rule "Unique data"
12 matches
Mail list logo