[JBoss JIRA] (WFLY-7282) Double diamond in EJB Transaction
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/WFLY-7282?page=com.atlassian.jira.plugin.... ]
Flavia Rainone updated WFLY-7282:
---------------------------------
Description:
At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.
was:At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.
Steps to Reproduce:
You need a reinvocation at a server that was already participating in the transaction, as the scenario below for example:
server1 -> server2 -> server1
> Double diamond in EJB Transaction
> ---------------------------------
>
> Key: WFLY-7282
> URL: https://issues.jboss.org/browse/WFLY-7282
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Fix For: 10.2.0.Final, 11.0.0.Alpha1
>
>
> At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7282) Double diamond in EJB Transaction
by Flavia Rainone (JIRA)
Flavia Rainone created WFLY-7282:
------------------------------------
Summary: Double diamond in EJB Transaction
Key: WFLY-7282
URL: https://issues.jboss.org/browse/WFLY-7282
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.1.0.Final
Reporter: Flavia Rainone
Assignee: Flavia Rainone
Fix For: 10.2.0.Final, 11.0.0.Alpha1
At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-1791) Strange operation-id handling in domain server reload execution
by Yeray Santana Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1791?page=com.atlassian.jira.plugi... ]
Yeray Santana Borges commented on WFCORE-1791:
----------------------------------------------
It seems the operation-id is sent back to the HC in this method: HostControllerConnection.ServerRegisterRequest.sendRequest. As far as I have been able to check, this is the sequence which enables the operation-id being sent back:
# Reload is executed in a domain mode, so HC sends the current operation-id in the reload operation to the managed server(s)
# On server(s) side, ServerDomainProcessReloadHandler is executed which updates the static instance variable DomainServerCommunicationServices.initialOperationID
# Server(s) is reloaded, the root service for an application server process is ApplicationServerService, its start() method is then invoked which activates two service activators: DomainServerCommunicationServices and an anonymous service activator created in ServerStartTask
# DomainServerCommunicationServices.activate is invoked which creates a new HostControllerConnectionService and installs it, so its HostControllerConnectionService.start method is invoked which creates a new HostControllerConnection instance. This instance is the instance used to send the operation-id back to the HC. In this point the HostControllerConnection has the operation-id updated in point 2) by the reload operation on server side.
# The anonymous service activator in ServerStartTask class is activated too. This class installs the ServerBootOperationsService service. This service in L68 invokes HostControllerClient.resolveBootUpdates which invokes HostControllerConnection.openConnection. The connection is then opened using ServerRegisterRequest which sends the operation-id the HC in ServerRegisterRequest.sendRequest.
# The server is registered then by the HC executing the register operation and without blocking since it has the correct operation-id received before.
> Strange operation-id handling in domain server reload execution
> ---------------------------------------------------------------
>
> Key: WFCORE-1791
> URL: https://issues.jboss.org/browse/WFCORE-1791
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Yeray Santana Borges
> Priority: Minor
>
> When the HC sends a reload op to a managed server it includes an undocumented "operation-id" parameter. But, I don’t see how it is used with a reload. When it was added to the code the intent clearly was that it would be used, but now at least is not. ServerDomainProcessReloadHandler reads it from the op and sets DomainServerCommunicationServices.initialOperationId, but that field is only read when HostControllerConnectionService is instantiated. HostControllerConnectionService then caches the value in a final field. A reload does not result in a new instantiation of HostControllerConnectionService; that object is only instantiated during initial process boot when ServerStartTask is unmarshaled from stdin and run. So changing the DomainServerCommunicationServices.initialOperationId in a reload should do nothing.
> https://github.com/wildfly/wildfly-core/commit/302949cf60823d8aa3989d74df... is the initial commit when this update of the id in reload was added in. The intent was that by providing this id, when the reloading server connects to the HC to get the boot ops, that read of boot ops would be able to "join" any active operation that triggered the reload, and thus would not have to block waiting for that operation to complete.
> Afaict, if the "blocking" param on an op like /host=x/server[-config]=y:reload is set to 'true' the op should deadlock. On the HC, ServerReloadHandler will acquire the exclusive lock by calling context.getServiceRegistry(true). Then ServerInventoryImpl.reloadServer will block waiting for the server to reach STARTED state. But the server won't reach that because it's registration request will not be able to acquire the HC lock.
> Task here is to
> 1) Confirm the above and then
> 2) Either
> a) get the operation-id propagated
> b) or rip the operation-id bit out of reload because investigation showed it was not needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-1791) Strange operation-id handling in domain server reload execution
by Yeray Santana Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1791?page=com.atlassian.jira.plugi... ]
Yeray Santana Borges reassigned WFCORE-1791:
--------------------------------------------
Assignee: Yeray Santana Borges
> Strange operation-id handling in domain server reload execution
> ---------------------------------------------------------------
>
> Key: WFCORE-1791
> URL: https://issues.jboss.org/browse/WFCORE-1791
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Yeray Santana Borges
> Priority: Minor
>
> When the HC sends a reload op to a managed server it includes an undocumented "operation-id" parameter. But, I don’t see how it is used with a reload. When it was added to the code the intent clearly was that it would be used, but now at least is not. ServerDomainProcessReloadHandler reads it from the op and sets DomainServerCommunicationServices.initialOperationId, but that field is only read when HostControllerConnectionService is instantiated. HostControllerConnectionService then caches the value in a final field. A reload does not result in a new instantiation of HostControllerConnectionService; that object is only instantiated during initial process boot when ServerStartTask is unmarshaled from stdin and run. So changing the DomainServerCommunicationServices.initialOperationId in a reload should do nothing.
> https://github.com/wildfly/wildfly-core/commit/302949cf60823d8aa3989d74df... is the initial commit when this update of the id in reload was added in. The intent was that by providing this id, when the reloading server connects to the HC to get the boot ops, that read of boot ops would be able to "join" any active operation that triggered the reload, and thus would not have to block waiting for that operation to complete.
> Afaict, if the "blocking" param on an op like /host=x/server[-config]=y:reload is set to 'true' the op should deadlock. On the HC, ServerReloadHandler will acquire the exclusive lock by calling context.getServiceRegistry(true). Then ServerInventoryImpl.reloadServer will block waiting for the server to reach STARTED state. But the server won't reach that because it's registration request will not be able to acquire the HC lock.
> Task here is to
> 1) Confirm the above and then
> 2) Either
> a) get the operation-id propagated
> b) or rip the operation-id bit out of reload because investigation showed it was not needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1318) Using java enum when setting a variable of type enum does not work
by Nicolas Heron (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1318?page=com.atlassian.jira.plugi... ]
Nicolas Heron commented on DROOLS-1318:
---------------------------------------
I did a small project to identify the problem https://github.com/nheron/use-case1
> Using java enum when setting a variable of type enum does not work
> ------------------------------------------------------------------
>
> Key: DROOLS-1318
> URL: https://issues.jboss.org/browse/DROOLS-1318
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.4.0.Final
> Reporter: Nicolas Heron
> Assignee: Mario Fusco
> Labels: OnBoarding
>
> In project https://github.com/chtiJBUG/onboarding-nautic-project
> when running the TestBirthday reduction
> TestBirthdayReduction : [Error: could not access/write property (seasonType) in: org.chtijbug.example.swimmingpool.Period] [Near :
> the source code of the rule is
> package org.training.leisure.swimmingpool;
> import java.lang.Number;
> import org.chtijbug.example.swimmingpool.CalculatedAttribute;
> import org.chtijbug.example.swimmingpool.Price;
> import org.chtijbug.example.swimmingpool.Person;
> import org.chtijbug.example.swimmingpool.Period;
> import org.chtijbug.example.swimmingpool.PriceType;
> rule "BirthdayReduction"
> dialect "mvel"
> ruleflow-group "reduction"
> when
> ccat : CalculatedAttribute( key == "IsPersonBirthday" , stringValue == "true" )
> pper : Person( calculatedAttributeList contains ccat , sprice : standardPrice > 0.0B )
> not (pprice : Price( description == "BirthdayReduction" ) and Person( priceList contains pprice , this == pper ))
> Period( seasonType == SeasonType.day )
> then
> Price nprice = new Price();
> nprice.setDescription( "BirthdayReduction" );
> nprice.setAmount( sprice.divide(new BigDecimal("10.0"),BigDecimal.ROUND_HALF_UP) );
> nprice.setPriceType( PriceType.promotion );
> insert( nprice );
> pper.addPrice( nprice );
> modify( pper ) {
> setPriceList( pper.getPriceList() )
> }
> end
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 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 updated DROOLS-1313:
----------------------------------
Attachment: SAVE_SimpleTest4.java
simpleTestThirdDump4.png
> 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, SAVE_SimpleTest4.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)
8 years, 3 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 reopened DROOLS-1313:
-----------------------------------
I added the code suggested, but the results reported by the Memory Analyzer appear to be the same as before. Please see the SAVE_SimpleTest4.java file and the simpleTestThirdDump4.png screenshot.
-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, 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)
8 years, 3 months
[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1313.
---------------------------------
Resolution: Rejected
I believe there isn't any leak. Old releases are just kept in the KieRepository. If you want to remove them you can do it programmatically with
{code}
KieServices.Factory.get().getRepository().removeKieModule( oldReleaseId );
{code}
Please try to add this to your code and if the problem persists feel free to reopen this ticket.
> 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)
8 years, 3 months
[JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1323:
-------------------------------------
Description:
Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve
was:Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-1323
> URL: https://issues.jboss.org/browse/DROOLS-1323
> Project: Drools
> Issue Type: Task
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Attachments: Selection_240.png, Selection_241.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months