[
https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on WFLY-1309:
-----------------------------------------------
Brian Stansberry <brian.stansberry(a)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
Components: Domain Management
Affects Versions: 8.0.0.Alpha1
Environment: wildfly build from a git clone on 2013-05-02
Reporter: Tom Fonteyne
Assignee: Brian Stansberry
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