[rules-users] drools expert: memory issues

[Leonardo Gomes]

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 at gmail.com>

> hi again,
>
> 2010/4/1 Edson Tirelli <ed.tirelli at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20100407/2dfbca46/attachment.html