I'm still using good old Drools 4 and there's an ant task and a maven plugin out there to compile your rules at build time. I'm pretty sure there's something like that you could use as well.

Cheers,
Leonardo.

2010/4/1 miguel machado <mls.machado@gmail.com>
hi again,

2010/4/1 Edson Tirelli <ed.tirelli@gmail.com>


   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"

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users