[ https://issues.jboss.org/browse/WFCORE-3977?page=com.atlassian.jira.plugi... ] Paul Ferraro commented on WFCORE-3977: -------------------------------------- [~brian.stansberry] In the case of JGroups, deferring restart of the Service<SocketBinding> until the socket is bound is too late. JGroups contains services which depend on socket-bindings for their configuration. They extract the address/port and configure the JGroups protocol accordingly. Let's take the example of /subsystem=jgroups/transport=tcp... This resource is configured with a socket-binding to which configures the TCP protocol with an InetAddress and port taken from the SocketBinding. This service starts on-demand, when required by an associated channel. In the "ha" profile, following startup of the server, the TCP protocol's Service<TransportConfiguration> will be DOWN (as no channel has forced it to start yet). Now a user issues an update of the associated address/port of TCP's socket-binding. The write-attribute operations will succeed, however, the corresponding Service<SocketBinding> will not restart, and the server is not put in reload-required, since this socket-binding is not bound (as you mentioned above). Next a user deploys a distributed application, which starts a channel, and triggers the start of TCP's Service<TransportConfiguration>, however it will use outdated socket address/port values. -- This message was sent by Atlassian JIRA (v7.5.0#75005)