[ https://issues.jboss.org/browse/AS7-1782?page=com.atlassian.jira.plugin.s... ] Stefano Maestri reassigned AS7-1782: ------------------------------------ Assignee: Stefano Maestri (was: Jonathan Halliday) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-1782?page=com.atlassian.jira.plugin.s... ] Stefano Maestri commented on AS7-1782: -------------------------------------- Isn't more clear with subresources? See AS7-923, and let me know what other informations needs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-1782?page=com.atlassian.jira.plugin.s... ] Heiko Braun updated AS7-1782: ----------------------------- Description: I cannot identify the use cases not the operation when looking at the current management exposure: {noformat} [standalone@localhost:9999 /] /subsystem=transactions:read-resource(recursive=true) { "outcome" => "success", "result" => { "default-timeout" => 300, "enable-statistics" => false, "enable-tsm-status" => false, "node-identifier" => "1", "object-store-path" => "tx-object-store", "object-store-relative-to" => "jboss.server.data.dir", "path" => "var", "process-id-socket-binding" => undefined, "process-id-socket-max-ports" => 10, "process-id-uuid" => true, "recovery-listener" => false, "relative-to" => "jboss.server.data.dir", "socket-binding" => "txn-recovery-environment", "status-socket-binding" => "txn-status-manager" } } {noformat} was: I cannot identify the use cases not the operation when looking at the current management exposure: {noformat} [standalone@localhost:9999 /] /subsystem=transactions:read-resource(recursive=true) { "outcome" => "success", "result" => { "coordinator-environment" => { "enable-statistics" => undefined, "enable-tsm-status" => undefined, "default-timeout" => 300 }, "core-environment" => { "process-id" => {"uuid" => "uuid"}, "node-identifier" => undefined, "relative-to" => undefined, "path" => undefined }, "object-store" => { "relative-to" => undefined, "path" => undefined }, "recovery-environment" => { "socket-binding" => "txn-recovery-environment", "status-socket-binding" => "txn-status-manager", "recovery-listener" => undefined } } } [standalone@localhost:9999 /] /subsystem=transactions:read-operation- read-operation-description read-operation-names [standalone@localhost:9999 /] /subsystem=transactions:read-operation-names { "outcome" => "success", "result" => [ "add", "read-attribute", "read-children-names", "read-children-resources", "read-children-types", "read-operation-description", "read-operation-names", "read-resource", "read-resource-description", "validate-address", "write-attribute" ] } {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-1782?page=com.atlassian.jira.plugin.s... ] Andrig Miller commented on AS7-1782: ------------------------------------ After thinking about this from my perspective, I believe what is exposed in the XML schema represents the three management use cases: 1) The default transaction timeout (as specified above from with the default-timeout attribute). Setting this lower or higher depending on the application can be important. There is also a proprietary @TransactionTimeout annotation that developers can use to override the default on a method basis within the application, but some developers may not want to use that, since it is not a spec annotation. 2) The location of the transaction log, as users may want to move it from under the distribution installation, to another location that is tuned for the performance needs of the transaction log. Also, many organizations like to install the software in a read-only file system, and have all the write locations on separate mount points/file systems. This will be something we probably do in our benchmarking efforts, to isolate the I/O, and make sure we are not creating an artificial bottleneck. 3) Finally, the transaction recovery environment configuration would the the only other thing. This relates to the socket binding, status socket binding, and the recovery listener. If the socket is used, then the socket binding and status socket binding have to be set along with telling the recovery listener to listen on a socket (true), if the uuid is used, then the socket bindings are unnecessary, and the recovery listener doesn't listen on the socket. I believe the UUID setup is the default due to OpenShift, which is fine. I'm not sure of any pros and cons between the two at this point in time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira