Re: [rules-users] drools expert: memory issues

hi there, So like i said, by pre-compiling the rules and loading them in the main system i was able to reduce a lot memory usage and i can get better results. However, now i've come across a different problem. I just added a fre more dozens of rules and the java program responsible for compiling the DRL file throws a java heap space error, something like an OutOfMemoryException. I've read somewhere that dividing the DRL into several files and loading e.g. 500 rules at a time might solve it. Is there another approach to this problem? thanks in advance, _ miguel On Thu, Apr 1, 2010 at 6:12 PM, miguel machado <mls.machado(a)gmail.com&gt;wrote: > hi again, > > 2010/4/1 Edson Tirelli <ed.tirelli(a)gmail.com&gt; > > >> Hmm, let me complement Wolfgang's comment: >> >> > After you have taken the compiled packages from the KB and checked for >> errors, the KB has done his duty the KB ****MUST**** go :-) >> > > I agree! But i don't exactly know how to do so... i mean, i call this > method which creates the KB from a DRL file and then the kbase and returns > the ksession, the KB object declaration scope is just that exact method, and > once it reaches 300MB+ in memory, it just stays there... the KB object is no > longer in use (or is it?) but memory keeps high. > > I've tried setting KB to "null" and then invoking the jvm garbage > collector, but to no avail. I wish there was a simple way i could just > destroy a particular object sigh > > >> >> The above emphasis is mine. KnowledgeBuilder is a higher level object >> designed to encapsulate the parsing+compilation steps of resources. It is >> **not** designed to be reused and doing so might create inconsistencies. The >> memory spike you see when using the kbuilder is due to the java compiler... > > > I understand that, and i'll have that if i must, but the thing is it's not > just a spike, it is prolonged throughout execution, it doesn't reduce > afterwards. > > >> Drools itself does not do anything fancy in there other than generate >> some code (quite inexpensive memory wise) and compile it using either JDT or >> JANINO (both quite expensive memory wise, when compared to the other steps). >> >> >> So, I strongly discourage you keeping the KB around and as mentioned >> by Wolfgang, doing so might keep unnecessary objects in memory. >> > > Like i said earlier, it's not that i want to keep KB around, i just can't > remove it. > > >> >> Also, just to clarify, deserializing a compiled package means the >> compiler will not be called (obviously, as everything is already compiled) >> and that is why it should save you memory. >> > > Thanks for clarifying that! I've tested with a separate application to > build a compiled file and then load it in the main system and it really > makes a difference! it's gone to <100MB wow! However, this was just a > proof-of-concept, as i'm not sure how i could apply the same technique to > the main standalone application. Do i really have to create a separate > process/application just for building/compiling the rules, to make sure the > compilation-object-junk doesn't stay in memory along with the rest? > > Thanks for all the feedback and input so far. > _ miguel > > > -- > "To understand what is recursion you must first understand recursion" > -- "To understand what is recursion you must first understand recursion" _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users