[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ]
Bill Tuminaro updated DROOLS-1313:
----------------------------------
Attachment: SimpleTest2_dump2.PNG
SimpleTest2_dump1.PNG
SimpleTest2_dump3.PNG
SAVE_SimpleTest2.java
> 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, SAVE_SimpleTest2.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, 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)
9 years, 7 months
[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ]
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)
9 years, 7 months
[JBoss JIRA] (DROOLS-1314) Compilation of spreadsheet fails with specific condition
by Alessandro Lazarotti (JIRA)
Alessandro Lazarotti created DROOLS-1314:
--------------------------------------------
Summary: Compilation of spreadsheet fails with specific condition
Key: DROOLS-1314
URL: https://issues.jboss.org/browse/DROOLS-1314
Project: Drools
Issue Type: Bug
Components: build, decision tables
Affects Versions: 6.4.0.Final
Reporter: Alessandro Lazarotti
Assignee: Michael Anstis
Priority: Critical
Fix For: 6.5.0.Final
Reproducer is attached.with problematic spredsheet named SampleNG.xml.
Compilation of this fails with the following error.
java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=dtables/SampleNG.xls, line=8, column=0
text=Unable to Analyse Expression checktest == AAA:
[Error: unable to resolve method using strict-mode: com.sample.DecisionTableTest$Message.AAA()]
[Near : {... checktest == AAA ....}]
because the following DRL is generated.
rule "HelloWorld_12"
when
m:Message(checktest in (AAA), status == "Message.HELLO")
...
i.e. double quotation of value ("AAA") specified in the cell is removed.
If D column does not exist like Sample.xml(also included in reproducer) or rule template of D column is modified like "status == $param " (see SampleOK.xml), this does not happen.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1760) Extension initialization handling makes use of PersistentResourceDefinition overly difficult
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1760?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-1760.
--------------------------------------
Fix Version/s: 3.0.0.Alpha9
Assignee: Tomaz Cerar
Resolution: Done
Tomaz solved this problem in a much much much simpler way with WFCORE-1831. :)
> Extension initialization handling makes use of PersistentResourceDefinition overly difficult
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-1760
> URL: https://issues.jboss.org/browse/WFCORE-1760
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Fix For: 3.0.0.Alpha9
>
>
> PersistentResourceXMLBuilder.build() requires a PersistentResourceDefinition as an input. This is a problem because the PersistentResourcXmlDefinition is needed to initialize parsers for Extension.initializeParsers(), which is called *before* Extension.initialize(). And Extension.initialize() is when the PersistentResourceDefinition would normally be constructed.
> An Extension implementation could overcome this by maintaining internal state. Construct the PersistentResourceDefinition in initializeParsers() and store it in an instance field for use in initialize(). Or vice versa. That gets messy though as now the Extension impl is needing to worry about the order in which the two methods are called and tracking whether both have been called so it can drop the cached object.
> A possible thing to do is the have the ExtensionContext and ExtensionParsingContext offer an attachment API, with the lifecycle of attachments documented as being scoped to a single overall extension initialization. That could work but isn't very elegant.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6784) Add possibility to enable websocket compression via management model
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6784?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-6784:
----------------------------------
[~swd847] [~iweiss] The PR has been reverted since it caused TCK failures. [~smarlow] can provide more details.
> Add possibility to enable websocket compression via management model
> --------------------------------------------------------------------
>
> Key: WFLY-6784
> URL: https://issues.jboss.org/browse/WFLY-6784
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Radim Hatlapatka
> Assignee: Ingo Weiss
> Priority: Critical
> Labels: downstream_dependency
> Fix For: 11.0.0.Alpha1
>
> Original Estimate: 2 days
> Time Spent: 2 days
> Remaining Estimate: 0 minutes
>
> In EAP 6 the websockets compression was enabled by default allowing to use pre-deflate compression when requested by client.
> There is support for it in Undertow but there is no option to enable it in WildFly 10. This option should be added to WildFly and should probably set by default to true as that would be consistent with default behaviour when using WebSockets with EAP 6.4.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6784) Add possibility to enable websocket compression via management model
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6784?page=com.atlassian.jira.plugin.... ]
Kabir Khan reopened WFLY-6784:
------------------------------
> Add possibility to enable websocket compression via management model
> --------------------------------------------------------------------
>
> Key: WFLY-6784
> URL: https://issues.jboss.org/browse/WFLY-6784
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Radim Hatlapatka
> Assignee: Ingo Weiss
> Priority: Critical
> Labels: downstream_dependency
> Fix For: 11.0.0.Alpha1
>
> Original Estimate: 2 days
> Time Spent: 2 days
> Remaining Estimate: 0 minutes
>
> In EAP 6 the websockets compression was enabled by default allowing to use pre-deflate compression when requested by client.
> There is support for it in Undertow but there is no option to enable it in WildFly 10. This option should be added to WildFly and should probably set by default to true as that would be consistent with default behaviour when using WebSockets with EAP 6.4.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ]
Bill Tuminaro commented on DROOLS-1313:
---------------------------------------
I forgot to mention, we have thousands of rules, we use the approach outlined above to try to avoid rewriting the entire kfs when rules change. When a rule changes, we simply delete the old file and add a new one with a new name into the existing KieFileSystem.
-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)
9 years, 7 months
[JBoss JIRA] (WFLY-7209) Operation to list installed Resource Adapters
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-7209?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero commented on WFLY-7209:
----------------------------------------------------
>From what I saw, it seemed to me that the resource adapter was automatically activated even without the ironjacamar.xml descriptor. I'll have to check it.
My use case is to list the currently deployed resource adapters (activated or not). As it currently works, in the web console you have to specify the deployment or module name by manually typing. This would basically allow graphical UIs to show a list of possible candidates, like it works for JDBC drivers.
As a side note, the resource-adapters subsystem is not listed on deployments (https://wildscribe.github.io/Wildfly/10.0.0.Final/deployment/index.html). Are there any technical reasons for that? Is it only present when there's an iconjacamar.xml descriptor present?
> Operation to list installed Resource Adapters
> ---------------------------------------------
>
> Key: WFLY-7209
> URL: https://issues.jboss.org/browse/WFLY-7209
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Reporter: Guillermo González de Agüero
> Assignee: Stefano Maestri
> Fix For: 10.1.0.Final
>
>
> Currently there's no way to list all the installed Resource Adapters. Only configured resource adapters can be queried. However, they are automatically enabled at deployment time.
> I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers. This would allow HAL to provide a wizard of available options when configuring them.
> The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management
by 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)
9 years, 7 months