[jboss-jira] [JBoss JIRA] (WFLY-1309) CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1309:
-----------------------------------

    Comment: was deleted

(was: Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 960292|https://bugzilla.redhat.com/show_bug.cgi?id=960292]

Impact analysis of the issue described in my last comment:

Infinispan 1.4.1 -> 1.4.0:

No negative impact. If the legacy "virtual-nodes" attribute is used, it will get transformed to "segments". This would happen on the slave side anyway.

Datasources 1.1.2 -> 1.1.0

No negative impact; API changes in 1.1.1 and 1.1.2 were to add missing API description metadata

EJB3 1.2.1 -> 1.2.0:

No negative impact; API change was related to runtime resources in the deployment tree and transformation is not relevant.

Messaging 1.2.1 -> 1.2.0:

Might result in some unnecessary WARN messages in the logs if the user uses the nonfunctional "clustered" attribute but declares a value that is inconsistent with the rest of the configuration. This would be an edge case and a misconfiguration anyway.

Security 1.2.1 -> 1.2.0:

This will result in the fix for the security subsystem aspect of https://bugzilla.redhat.com/show_bug.cgi?id=908714 not working (see https://issues.jboss.org/browse/WFLY-108 for a less cluttered description of the security subsystem issue). The "two part, first is that one transformer is buggy" bit that Tomaz mentioned is the cause of this not working; if not for that it would be fine.

Other extensions:

Other extensions not part of the EAP code base (i.e. layered product extensions or end user developed extensions) may have problems, although IMO this is unlikely.


So, it seems the "second more important is that transfomrers should not even been fired as all host controllers are same version" aspect of this report is not that critical an issue.

The security subsystem part may result in CLI scripts written against EAP 6.0.x not working because the bz 908714 fix is broken, but there is a workaround to this problem; simply adapt the scripts to the EAP 6.1 variant of the API.)

    
> CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1309
>                 URL: https://issues.jboss.org/browse/WFLY-1309
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha1
>         Environment: wildfly build from a git clone on 2013-05-02
>            Reporter: Tom Fonteyne
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>         Attachments: host-domain-controller.xml, host-slave.xml
>
>
> Setup two boxes:
> - on one, run domain mode (full-ha) -> domain controller
> - on the other, configure host.xml to point to the DC, and run the host controller
> Now in CLI:
> # add the group:
> /server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
> # create server and set a prop
> batch
> /host=slave1/server-config=i1:add(group=slaves,auto-start=false)
> /host=slave1/server-config=i1/system-property=env:add(value=dev)
> run-batch 
> results in:
> JBAS010839: Operation failed or was rolled back on all servers.
> Debugging (on EAP 6.0.1) showed the real reason:
> activeStep.response = (org.jboss.dmr.ModelNode) {
>      "outcome" => "failed",
>      "failure-description" => "JBAS010850: No handler for operation
> composite at address [
>      (\"host\" => \"slave1\"),
>      (\"server\" => \"i1\")
> ]",
>      "rolled-back" => true
> } 
> More debugging led to :
> org.jboss.as.controller.AbstractOperationContext
> seems to be where the rollback is set. When debugging, I found that the constructor always sets
>      ModelController.OperationTransactionControl transactionControl
> but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
>         // Allow any containing TransactionControl to vote
>         final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
> and ref becomes a rollback.
> I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
> But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira