[ https://issues.jboss.org/browse/AS7-4468?page=com.atlassian.jira.plugin.s... ] Kabir Khan reassigned AS7-4468: ------------------------------- Assignee: Kabir Khan (was: Brian Stansberry) -- 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-4468?page=com.atlassian.jira.plugin.s... ] Kabir Khan commented on AS7-4468: --------------------------------- The above comment is what happens if NO servers are associated with the socket-binding-group. With the reload-required state set for affected servers the output is fine {code} [domain@localhost:9999 /] /socket-binding-group=full-sockets:remove { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => { "server-one" => { "host" => "master", "response" => {"outcome" => "success"} }, "server-two" => { "host" => "master", "response" => {"outcome" => "success"} } }} } {code} -- 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-4468?page=com.atlassian.jira.plugin.s... ] Kabir Khan commented on AS7-4468: --------------------------------- Setting it in the reload-required state is a signal to the user that there are no guarantees that the change results in a properly configured server, and that the affected server should be restarted. This now happens following the remove call. But now that you mention it, the new state should probably be reported in the individual results. I'll take a look at what happens for a standalone server and adjust if necessary. -- 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-4468?page=com.atlassian.jira.plugin.s... ] Kabir Khan commented on AS7-4468: --------------------------------- This might need more work, I am checking with Brian. The problem is that your 2) will currently cause the same error since I am not removing the socket binding group as part of the remove operation. Removing that service has its own problems since other services depend on that. With what is there it would be possible to 1) remove the group 2) restart the server in admin-only mode 3) add the group 4) restart the server in normal mode -- 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-4468?page=com.atlassian.jira.plugin.s... ] Kabir Khan commented on AS7-4468: --------------------------------- After talking to Brian we decided to keep it the way it works in my branch with a small tweak, in that the add handler only tries to install the service while booting. So the flow will be 1) server running normally 2) remove group -> reload-required state 3) add group - does not try to add the service since it is not booting, and puts the server in reload-required (again) 4) restart server -- 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-4468?page=com.atlassian.jira.plugin.s... ] Michael Voegele reopened AS7-4468: ---------------------------------- I am working on 7.1.2.Final-SNAPSHOT and checked this. Removing a socket-binding-group will also remove all socket-bindings. Readding the socket-binding-group now works, but readding a socket-binding leads to: { "port" => big integer 8009, "operation" => "add", "address" => [ ("socket-binding-group" => "standard-sockets"), ("socket-binding" => "ajp") ] } { "outcome" => "failed", "result" => undefined, "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.", "rolled-back" => true, "server-groups" => {"server-group-1" => {"host" => {"master" => {"server-1" => {"response" => { "outcome" => "failed", "failure-description" => "JBAS014749: Operation handler failed: Service jboss.binding.ajp is already registered", "rolled-back" => true, "response-headers" => {"process-state" => "restart-required"} }}}}}} } -> add socket-binding should also not try to add the service... -- 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-4468?page=com.atlassian.jira.plugin.s... ] Kabir Khan commented on AS7-4468: --------------------------------- I'm not sure we can clean up the services since that would lead to unsatisfied dependencies which causes the remove to get rolled back. restart-required means you need to restart, so if I do the following (very inelegant) sequence I manage to do it {code} [domain@localhost:9999 /] /socket-binding-group=full-sockets:remove { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } }}, "server-two" => {"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } }} }}}} } [domain@localhost:9999 /] /server-group=main-server-group:restart-servers { "outcome" => "failed", "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS010981: Included socket binding group full-sockets is not defined"}, "rolled-back" => true } <<<< Here server-one gets stopped but fails to start again, server-two is still running >>>>>> [domain@localhost:9999 /] /socket-binding-group=full-sockets:add(default-interface=public) { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-two" => {"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } }}}}}} } [domain@localhost:9999 /] /server-group=main-server-group:restart-servers { "outcome" => "success", "result" => undefined, "server-groups" => undefined } <<<< Server-two gets started. server-one needs the start call to start >>>>>> [domain@localhost:9999 /] /server-group=main-server-group:start-servers { "outcome" => "success", "result" => undefined, "server-groups" => undefined } <<<< Both servers are started with missing depenendencies >>>>>> [domain@localhost:9999 /] /socket-binding-group=full-sockets/socket-binding=http:add(port=8080) { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => {"outcome" => "success"}}, "server-two" => {"response" => {"outcome" => "success"}} }}}} } <<<< http now works on both servers >>>>>> {code} I totally admit that this sucks :-) I'll try to make the socket-binding-group remove fail instead with a meaningful error message if there are running servers using that socket-binding-group. -- 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-4468?page=com.atlassian.jira.plugin.s... ] Michael Voegele edited comment on AS7-4468 at 6/8/12 8:19 AM: -------------------------------------------------------------- To achieve the same (changing ports for servers), instead of removing the whole socket-binding-group, readding it again and then readding all the socket-bindings, it is possible to just use write-attribute in the following way (after writing the new ports, the server-group can be restarted...): {code:xml} <dmr-operation-template id="template_socket-binding-group"> <dmr-operation-set id="socket-binding-group"> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="socket-binding" value="http" /> <json> <![CDATA[ { "name":"port", "value":${socket-binding.port.http} } ]]> </json> </dmr-operation> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="socket-binding" value="https" /> <json> <![CDATA[ { "name":"port", "value":${socket-binding.port.https} } ]]> </json> </dmr-operation> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="socket-binding" value="osgi-http" /> <json> <![CDATA[ { "name":"port", "value":${socket-binding.port.osgi-http} } ]]> </json> </dmr-operation> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="socket-binding" value="remoting" /> <json> <![CDATA[ { "name":"port", "value":${socket-binding.port.remoting} } ]]> </json> </dmr-operation> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="socket-binding" value="txn-recovery-environment" /> <json> <![CDATA[ { "name":"port", "value":${socket-binding.port.txn-recovery-environment} } ]]> </json> </dmr-operation> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="socket-binding" value="txn-status-manager" /> <json> <![CDATA[ { "name":"port", "value":${socket-binding.port.txn-status-manager} } ]]> </json> </dmr-operation> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="remote-destination-outbound-socket-binding" value="mail-smtp" /> <json> <![CDATA[ { "name":"host", "value":"${socket-binding.host.mail-smtp}" } ]]> </json> </dmr-operation> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="remote-destination-outbound-socket-binding" value="mail-smtp" /> <json> <![CDATA[ { "name":"port", "value":${socket-binding.port.mail-smtp} } ]]> </json> </dmr-operation> </dmr-operation-set> </dmr-operation-template> {code} The following would just have been more elegant: {code:xml} <dmr-operation-template id="template_socket-binding-group"> <dmr-operation-set id="socket-binding-group"> <dmr-operation name="add" removeIfExisting="true"> <address-element key="socket-binding-group" value="${socket-binding.group}" /> <json> <![CDATA[ { "name":"${socket-binding.group}", "default-interface":"public" } ]]> </json> <dmr-operation name="add"> <address-element key="socket-binding" value="ajp" /> <json>{"port":${socket-binding.port.ajp}}</json> </dmr-operation> <dmr-operation name="add"> <address-element key="socket-binding" value="http" /> <json>{"port":${socket-binding.port.http}}</json> </dmr-operation> <dmr-operation name="add"> <address-element key="socket-binding" value="https" /> <json>{"port":${socket-binding.port.https}}</json> </dmr-operation> <dmr-operation name="add"> <address-element key="socket-binding" value="osgi-http" /> <json>{"interface":"management","port":${socket-binding.port.osgi-http}}</json> </dmr-operation> <dmr-operation name="add"> <address-element key="socket-binding" value="remoting" /> <json>{"port":${socket-binding.port.remoting}}</json> </dmr-operation> <dmr-operation name="add"> <address-element key="socket-binding" value="txn-recovery-environment" /> <json>{"port":${socket-binding.port.txn-recovery-environment}}</json> </dmr-operation> <dmr-operation name="add"> <address-element key="socket-binding" value="txn-status-manager" /> <json>{"port":${socket-binding.port.txn-status-manager}}</json> </dmr-operation> <dmr-operation name="add"> <address-element key="remote-destination-outbound-socket-binding" value="mail-smtp" /> <json>{"host":"${socket-binding.host.mail-smtp}","port":${socket-binding.port.mail-smtp}}</json> </dmr-operation> </dmr-operation> </dmr-operation-set> </dmr-operation-template> {code} With 'removeIfExisting="true"', the inverse operation of the defined operation is executed first. And this only has to be done on the parent (the socket-binding-group). was (Author: mvoegele): To achieve the same (changing ports for servers), instead of removing the whole socket-binding-group, readding it again and then readding all the socket-bindings, it is possible to just use write-attribute in the following way: {code:xml} <dmr-operation-template id="template_socket-binding-group"> <dmr-operation-set id="socket-binding-group"> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="socket-binding" value="http" /> <json> <![CDATA[ { "name":"port", "value":${socket-binding.port.http} } ]]> </json> </dmr-operation> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="socket-binding" value="https" /> <json> <![CDATA[ { "name":"port", "value":${socket-binding.port.https} } ]]> </json> </dmr-operation> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="socket-binding" value="osgi-http" /> <json> <![CDATA[ { "name":"port", "value":${socket-binding.port.osgi-http} } ]]> </json> </dmr-operation> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="socket-binding" value="remoting" /> <json> <![CDATA[ { "name":"port", "value":${socket-binding.port.remoting} } ]]> </json> </dmr-operation> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="socket-binding" value="txn-recovery-environment" /> <json> <![CDATA[ { "name":"port", "value":${socket-binding.port.txn-recovery-environment} } ]]> </json> </dmr-operation> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="socket-binding" value="txn-status-manager" /> <json> <![CDATA[ { "name":"port", "value":${socket-binding.port.txn-status-manager} } ]]> </json> </dmr-operation> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="remote-destination-outbound-socket-binding" value="mail-smtp" /> <json> <![CDATA[ { "name":"host", "value":"${socket-binding.host.mail-smtp}" } ]]> </json> </dmr-operation> <dmr-operation name="write-attribute"> <address-element key="socket-binding-group" value="${socket-binding-group}" /> <address-element key="remote-destination-outbound-socket-binding" value="mail-smtp" /> <json> <![CDATA[ { "name":"port", "value":${socket-binding.port.mail-smtp} } ]]> </json> </dmr-operation> </dmr-operation-set> </dmr-operation-template> {code} The following would just have been more elegant: {code:xml} <dmr-operation-template id="template_socket-binding-group"> <dmr-operation-set id="socket-binding-group"> <dmr-operation name="add" removeIfExisting="true"> <address-element key="socket-binding-group" value="${socket-binding.group}" /> <json> <![CDATA[ { "name":"${socket-binding.group}", "default-interface":"public" } ]]> </json> <dmr-operation name="add"> <address-element key="socket-binding" value="ajp" /> <json>{"port":${socket-binding.port.ajp}}</json> </dmr-operation> <dmr-operation name="add"> <address-element key="socket-binding" value="http" /> <json>{"port":${socket-binding.port.http}}</json> </dmr-operation> <dmr-operation name="add"> <address-element key="socket-binding" value="https" /> <json>{"port":${socket-binding.port.https}}</json> </dmr-operation> <dmr-operation name="add"> <address-element key="socket-binding" value="osgi-http" /> <json>{"interface":"management","port":${socket-binding.port.osgi-http}}</json> </dmr-operation> <dmr-operation name="add"> <address-element key="socket-binding" value="remoting" /> <json>{"port":${socket-binding.port.remoting}}</json> </dmr-operation> <dmr-operation name="add"> <address-element key="socket-binding" value="txn-recovery-environment" /> <json>{"port":${socket-binding.port.txn-recovery-environment}}</json> </dmr-operation> <dmr-operation name="add"> <address-element key="socket-binding" value="txn-status-manager" /> <json>{"port":${socket-binding.port.txn-status-manager}}</json> </dmr-operation> <dmr-operation name="add"> <address-element key="remote-destination-outbound-socket-binding" value="mail-smtp" /> <json>{"host":"${socket-binding.host.mail-smtp}","port":${socket-binding.port.mail-smtp}}</json> </dmr-operation> </dmr-operation> </dmr-operation-set> </dmr-operation-template> {code} With 'removeIfExisting="true"', the inverse operation of the defined operation is executed first. And this only has to be done on the parent (the socket-binding-group). After writing the new ports, the server-group can be restarted... -- 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