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

[Bill Tuminaro (JIRA)]

Bill Tuminaro created DROOLS-1313:
-------------------------------------

             Summary: 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)