[rules-users] Out of memory problem

Edson Tirelli tirelli at post.com
Wed Aug 29 08:34:28 EDT 2007


   Eymeric,

   I think what you have there is a combinatorial explosion. I.e. 5
patterns, all of the same type, doing an almost full cross product (limited
only by the type attribute constraint). If you check the agenda I would
expect to see a huge number of activations (it should be all possible
combinations of your 53 objects).

   Anyway, there are a few fixes made to 4.0.1, including some that affect
memory usage. One of the fixes we did was for increasing number of rule
fires, as you can see in the following test case. Look for testOutOfMemory()
method. It is a bit different of what you do, but using default 64Mb heap
configuration, I left the test running 100million+ rule firings and the
memory didn't blow up. The test is now limited to 3million fires so we can
keep it as part of our build process. Before the fix, it was raising OOME on
1.7million fires.

http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-compiler/src/test/java/org/drools/integrationtests/MiscTest.java

   Personally I think 53 objects is absurdly low. We have real use cases of
companies asserting millions of facts into the working memory at once and it
works just fine, with real rule sets of hundreds of rules. Maybe they
manifest themselves after reading this message.

   If you think this is indeed a problem, may I ask you please to open a
JIRA and submit us a self contained test showing the problem? I will profile
your test and determine the causes and if it is a problem on the engine, I
will fix it.

   Thank you,
     Edson

2007/8/29, Eymeric VIEUILLE <evieuille at gfi.fr>:
>
> Hi !
>
> I am currently leading a study that compares BRMS. The aim of this study
> is to determine if a rules engine can be used for our application and
> what rules engine to use.
>
> I made a prototype and I encountered a big problem of memory : no more
> than 53 objects could be passed as facts. After this threshold, I
> encountered a java.lang.OutOfMemoryException :
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>
> I increased the memory allocated to the JVM, but the more I insert
> objects as Facts and the more Drools becomes slower !
>
> I think that the problem is exactly the same as the following one :
> http://lists.jboss.org/pipermail/rules-users/2007-August/002592.html
>
> Can you confirm to me that is the same problem ? And in a positive
> affirmation, how to solve this problem ? And how much time would it take ?
>
> I am using drools 4.0 (developing whith associated eclipse IDE).
>
> I realized a dslr that looks like this :
> package com.sample
>
> import XXX.Message;
> import XXX.MyObject;
>
> expander leg_recognizer.dsl
>
> rule "rule 1"
>     no-loop true
>     when
>         $m1 is an "OUT" marker
>         $m2 is an "OFF" marker
>         $m3 is an "ON" marker
>         $m4 is an "IN" marker
>         $m4 event date is more than $m1 event date
>     then
>         print "Rule 1"
>         display message $m1
>         display message $m2
>         display message $m3
>         display message $m4
>         make $m1 treated
>         make $m2 treated
>         make $m3 treated
>         make $m4 treated
>         create a object "1" with state "active";
> end
>
> rule "rule 2".............(same principle) --> 6 rules in the real file.
>
> And it uses the following dsl file :
> [condition][]{message} is an "{state}" marker={message} : Message(type
> == "{state}")
> [consequence][]print "{string}"=System.out.println("{string}");
> [consequence][]display message {object}=System.out.println("Message : "
> + {object});
> [consequence][]create a object "{id}" with state "{state}"=insert(new
> MyObject("{id}", "{state}"));
> [consequence][]make {message} treated=retract({message});
> [condition][]{message1} event date is more than {message2} event
> date=eval({message1}.isALaterEventThanMessage({message2}))
>
> Did I made a mistake in the use of Drools or is this a bug ?
>
> Thanks for answers...That's quite urgent !
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070829/708b8b0f/attachment.html 


More information about the rules-users mailing list