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

[Mario Fusco (JIRA)]

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

Mario Fusco commented on DROOLS-1313:
-------------------------------------

There are 2 distinct things to be considered here:

1. Will this work? 
Also looking at what it does internally, yes I believe your approach is ok (for now, see 2.).

2. Is this supported?
Every time you use an internal class (not belonging to public kie api) you are doing something that by definition is not supported. We don't give any guarantee that those internal classes will remain as they are now and their behaviour can change literally at any new commit.

I hope this helps,
Mario


> 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: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SAVE_SimpleTest5.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.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)