[rules-users] Drools Classloader Leak?

Mark Proctor mproctor at codehaus.org
Sun May 9 19:20:06 EDT 2010


Drools is a dynamic system, the different classloaders is to try and 
allow partial reloading of classes, without having to reload everything. 
If we had a single classloader, we would have to reload everything, for 
every change.

Mark
On 07/05/2010 22:49, Moe Alkhafaji wrote:
> Interesting. Is there a reason for that? That doesn't sound too
> efficient. How can I get around it so that everything in the drools
> API uses the same default application classloader? Is there a setting
> or configuration somewhere that would tell drools to just use the
> default classloader? That would speed up the application, and require
> less perm gen memory.
>
> Thanks.
>
> Sent from my iPhone
>
> On May 7, 2010, at 4:30 PM, Mark Proctor<mproctor at codehaus.org>  wrote:
>
>    
>> Each kbase has it's own root classloader, and then an additional child
>> classloader per package in the kbase.
>>
>> Mark
>> On 07/05/2010 22:08, malkhafaji wrote:
>>      
>>> Hello,
>>>
>>> I noticed (using JConsole) that my application keeps loading more
>>> and more
>>> classes. I have over 105K classes loaded! I did a lot of debugging
>>> and
>>> isolation until I found the line that brings the number of classes
>>> loaded
>>> from 20K to 105K. It is this line:
>>>
>>> this.knowledgeBase.addKnowledgePackages(packages);
>>>
>>> packages is an array list of 8 DRLs that are compiled successfully.
>>> I am
>>> calling the line above exactly 99 times. However, I do have 99
>>> instances of
>>> this.knowledgeBase. So, I have a total of 99 instances of
>>> "knowledgeBase",
>>> and each instance is called once (line above) with 8 successfully
>>> compiled
>>> DRLs.
>>>
>>> I am starting to think that each instance of a KnowledgeBase
>>> somehow uses
>>> its own Classloader? Do I need to manually get the current
>>> application
>>> Classloader and pass it on to each instance of KnowledgeBase to
>>> ensure that
>>> no classes are loaded more than once? Is this a leak in the
>>> Classloader that
>>> comes inside the KnowledgeBase.addKnowledgePackage method? I did post
>>> somewhere else about delays on the line above, and no wonder it
>>> sometimes
>>> takes a couple of seconds to execute that line (the largest rules
>>> file I
>>> have is 150 KB with no more than 100 rules) if it creates a new
>>> Classloader
>>> and loads the same loaded classes AGAIN. Any insights on this?
>>>
>>> P.S. I did a search on the forum and couldn't find anything related
>>> to this.
>>> If you have better searching skills and found a post in that
>>> regards, please
>>> kindly point me to it. This is a very important issue as we are
>>> going to a
>>> live production environment in 3 weeks and I am not too happy with
>>> the
>>> performance, specifically around the line above.
>>>
>>> Thank you, and have a great weekend.
>>>
>>>        
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>      
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>    





More information about the rules-users mailing list