[jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management

[Bill Tuminaro (JIRA)]

    [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13300586#comment-13300586 ] 

Bill Tuminaro commented on DROOLS-1313:
---------------------------------------

I wrote another reproducer (SAVE_SimpleTest2.java) that uses the approach outlined in the org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest.java code.

I am really confused now, this approach seems to generate even more classloaders, classes and instances.

Can you shed some light on what the correct way to dynamically modify the rules in a module AND not keep consuming memory/heap space?

I have attached the code and 3 MAT screenshots.

-BillT


> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: SAVE_SimpleTest.java, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)