[JBoss JIRA] (WFCORE-1791) Strange operation-id handling in domain server reload execution
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1791:
----------------------------------------
Summary: 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: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
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)
9 years, 9 months
[JBoss JIRA] (WFCORE-1791) Strange operation-id handling in domain server reload execution
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1791?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1791:
----------------------------------------
Assignee: (was: Brian Stansberry)
> 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: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
>
> 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)
9 years, 9 months
[JBoss JIRA] (WFCORE-1775) CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1775?page=com.atlassian.jira.plugi... ]
Ivan Straka commented on WFCORE-1775:
-------------------------------------
Thank you.
> CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1775
> URL: https://issues.jboss.org/browse/WFCORE-1775
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ivan Straka
> Assignee: Brian Stansberry
>
> If I execute
> {code}
> /host=slave/core-service=management/service=configuration-changes:add(history-size=10)
> {code}
> on host controller, everything is fine.
> But, if
> {code}
> /core-service=management/service=configuration-changes:add(history-size=10)
> {code}
> is executed,
> {code:json}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYDC0032: Operation add for address [
> (\"core-service\" => \"management\"),
> (\"service\" => \"configuration-changes\")
> ] can only be handled by the master Domain Controller; this host is not the master Domain Controller",
> "rolled-back" => true
> }
> {code}
> is returned.
> I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC.
> This jira is supposed to start a discussion about this - is it a bug, or correct behavior?
> IMHO results of these two commands should should be the same.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1283) Memory leak using KieBuilder.build() method.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1283?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1283:
-------------------------------------
I reproduced the problem in a simpler way using the test case I'm pasting below. There isn't any assertion there but you can see the memory occupation constantly increasing at each loop.
{code}
@Test
public void testCreateKieBaseInLoop() {
final String drl = "package " + this.getClass().getPackage().getName() + ";" +
" rule R1 \n" +
" when \n" +
" String() \n" +
" then \n" +
" end ";
final KieResources kieResources = KieServices.Factory.get().getResources();
final org.kie.api.io.Resource drlResource = kieResources.newByteArrayResource( drl.getBytes(), "UTF-8" );
drlResource.setTargetPath("src/main/resources/rule.drl");
while (true) {
createKieBase(drlResource);
System.out.println(getUsedMemory());
}
}
private void createKieBase(final org.kie.api.io.Resource... resources ) {
final KieHelper kieHelper = new KieHelper();
for ( org.kie.api.io.Resource resource : resources) {
kieHelper.addResource(resource);
}
kieHelper.build();
}
private long getUsedMemory() {
System.gc();
final Runtime runtime = Runtime.getRuntime();
return runtime.totalMemory() - runtime.freeMemory();
}
{code}
The leak is not a real leak but only caused by the fact that all kcontainers are stored in this map https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/main...
The kcontainers will be removed by that map when calling dispose() on the single kcontainer itself. The problem is that nobody is calling that dispose() method, even in our own KieHelper. Also we are not sure if we want to rely on the fact that the users will always call that dispose() method (that however is still not exposed in the public API) so we are still discussing all possible solutions.
> Memory leak using KieBuilder.build() method.
> ---------------------------------------------
>
> Key: DROOLS-1283
> URL: https://issues.jboss.org/browse/DROOLS-1283
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.CR1
> Reporter: Tibor Zimányi
> Assignee: Mario Fusco
> Labels: regression, reported-by-qe
>
> There is a memory leak when building KieBase using KieBuilder.build() method. When continuously calling kieBuilder.build() (also with no resources), the OOM exception occurs.
> I will make PR with a reproducer for this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-3759) Make IP address of remote EJB client accessible to the developer from within app authentication code
by Bilge Ozpeynirci (JIRA)
[ https://issues.jboss.org/browse/WFLY-3759?page=com.atlassian.jira.plugin.... ]
Bilge Ozpeynirci updated WFLY-3759:
-----------------------------------
Summary: Make IP address of remote EJB client accessible to the developer from within app authentication code (was: Make IP address of remote EJB client accessible from within a login module)
> Make IP address of remote EJB client accessible to the developer from within app authentication code
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3759
> URL: https://issues.jboss.org/browse/WFLY-3759
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
>
> Make the IP address of remote EJB clients accessible from within a login module login module when the security-realm is configured to defer to JAAS.
> This is possible when the authentication is handled by the security-realm, but it is not possible when the security-realm defers to a security-domain (JAAS).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1785) Extension remove is not cleaning out provided capabilities
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1785?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1785:
------------------------------------------
Yes, this is a general problem with the extension remove handling, and is not specific to any particular extension.
> Extension remove is not cleaning out provided capabilities
> ----------------------------------------------------------
>
> Key: WFCORE-1785
> URL: https://issues.jboss.org/browse/WFCORE-1785
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha7
> Reporter: Jan Tymel
> Assignee: Tomaz Cerar
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha8
>
>
> It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly.
> Actual result:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.",
> "rolled-back" => true
> }
> {code}
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.
> at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518)
> at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
> at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669)
> at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368)
> at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226)
> at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83)
> at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226)
> at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694)
> at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99)
> at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131)
> at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> Expected result:
> It is possible to add Elytron subsystem after its removal.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1790) Invalid value-type for some operation arguments
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1790?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise closed WFCORE-1790.
----------------------------------------
Resolution: Rejected
This is not a bug, but a valid data representation.
> Invalid value-type for some operation arguments
> -----------------------------------------------
>
> Key: WFCORE-1790
> URL: https://issues.jboss.org/browse/WFCORE-1790
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Server
> Reporter: Jean-Francois Denise
> Assignee: Darran Lofthouse
>
> vault:add and authentication=<x>:add have arguments of type OBJECT with a value-type of STRING. The arguments passed to the operations are complex-type, so the value-type should be containing the complex type description.
> Examples:
> /core-service=vault:add(vault-options={KEYSTORE_PASSWORD=>MASK-20OB41ZkH8YzlPTICpKg5.,KEYSTORE_ALIAS=>jboss,SALT=>12345678,ITERATION_COUNT=>50,ENC_FILE_DIR=>/path/to/enc/file})
> /subsystem=security/security-domain=test/authentication=classic:add(login-modules=[{code=UsersRoles,flag=required,module-options={usersProperties=$\{jboss.server.config.dir\}/users.properties,rolesProperties=$\{jboss.server.config.dir\}/roles.properties}}]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1790) Invalid value-type for some operation arguments
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1790?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1790:
----------------------------------------------
Oh, I missed the Map data structure... I will close the bug and will take a second look to my fix.
> Invalid value-type for some operation arguments
> -----------------------------------------------
>
> Key: WFCORE-1790
> URL: https://issues.jboss.org/browse/WFCORE-1790
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Server
> Reporter: Jean-Francois Denise
> Assignee: Darran Lofthouse
>
> vault:add and authentication=<x>:add have arguments of type OBJECT with a value-type of STRING. The arguments passed to the operations are complex-type, so the value-type should be containing the complex type description.
> Examples:
> /core-service=vault:add(vault-options={KEYSTORE_PASSWORD=>MASK-20OB41ZkH8YzlPTICpKg5.,KEYSTORE_ALIAS=>jboss,SALT=>12345678,ITERATION_COUNT=>50,ENC_FILE_DIR=>/path/to/enc/file})
> /subsystem=security/security-domain=test/authentication=classic:add(login-modules=[{code=UsersRoles,flag=required,module-options={usersProperties=$\{jboss.server.config.dir\}/users.properties,rolesProperties=$\{jboss.server.config.dir\}/roles.properties}}]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1790) Invalid value-type for some operation arguments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1790?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1790:
------------------------------------------
Generally Map<String, String> type attributes are discouraged because they can't be fully self-describing. But in some cases there's really no alternative, as the attribute is configuring some plugin point and we can't know in advance what options are supported by that plugin.
> Invalid value-type for some operation arguments
> -----------------------------------------------
>
> Key: WFCORE-1790
> URL: https://issues.jboss.org/browse/WFCORE-1790
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Server
> Reporter: Jean-Francois Denise
> Assignee: Darran Lofthouse
>
> vault:add and authentication=<x>:add have arguments of type OBJECT with a value-type of STRING. The arguments passed to the operations are complex-type, so the value-type should be containing the complex type description.
> Examples:
> /core-service=vault:add(vault-options={KEYSTORE_PASSWORD=>MASK-20OB41ZkH8YzlPTICpKg5.,KEYSTORE_ALIAS=>jboss,SALT=>12345678,ITERATION_COUNT=>50,ENC_FILE_DIR=>/path/to/enc/file})
> /subsystem=security/security-domain=test/authentication=classic:add(login-modules=[{code=UsersRoles,flag=required,module-options={usersProperties=$\{jboss.server.config.dir\}/users.properties,rolesProperties=$\{jboss.server.config.dir\}/roles.properties}}]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1790) Invalid value-type for some operation arguments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1790?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1790:
------------------------------------------
An attribute of type OBJECT with a value-type of STRING is equivalent to a Map<String,String>. A Map has no predefined set of valid keys, so there is no full description of keys and values.
>From https://docs.jboss.org/author/display/WFLY/Admin+Guide#AdminGuide-Descrip...
value-type – ModelType or complex structure – Only present if type is LIST or OBJECT. If all elements in the LIST or all the values of the OBJECT type are of the same type, this will be one of the ModelType enums BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LONG, STRING. Otherwise, value-type will detail the structure of the attribute value, enumerating the value's fields and the type of their value.
So, if the type of the ModelNode for the value-type description is ModelType.TYPE, then the attribute is a Map<String, X> where X is indicated by the enum value. If the type of the ModelNode for the value-type description is ModelType.OBJECT, then the keys in the object are the legal fields and the values are the description of the field.
> Invalid value-type for some operation arguments
> -----------------------------------------------
>
> Key: WFCORE-1790
> URL: https://issues.jboss.org/browse/WFCORE-1790
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Server
> Reporter: Jean-Francois Denise
> Assignee: Darran Lofthouse
>
> vault:add and authentication=<x>:add have arguments of type OBJECT with a value-type of STRING. The arguments passed to the operations are complex-type, so the value-type should be containing the complex type description.
> Examples:
> /core-service=vault:add(vault-options={KEYSTORE_PASSWORD=>MASK-20OB41ZkH8YzlPTICpKg5.,KEYSTORE_ALIAS=>jboss,SALT=>12345678,ITERATION_COUNT=>50,ENC_FILE_DIR=>/path/to/enc/file})
> /subsystem=security/security-domain=test/authentication=classic:add(login-modules=[{code=UsersRoles,flag=required,module-options={usersProperties=$\{jboss.server.config.dir\}/users.properties,rolesProperties=$\{jboss.server.config.dir\}/roles.properties}}]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months