Rich DiCroce created WFLY-11807: ----------------------------------- Summary: Better port configuration for JGroups FD_SOCK Key: WFLY-11807 URL: https://issues.jboss.org/browse/WFLY-11807 Project: WildFly Issue Type: Enhancement Components: Clustering Affects Versions: 14.0.0.Final Reporter: Rich DiCroce Assignee: Paul Ferraro The JGroups FD_SOCK protocol requires 2 TCP sockets. Older versions of WildFly accepted a socket-binding for this protocol, but that was removed around version 11, apparently because the binding's port number [wasn't actually used|https://access.redhat.com/solutions/3485801]. Now the port selection is random by default, which is a problem if you've got firewalls to deal with, as noted in the linked document. The suggested workaround is to set the client_bind_port and start_port properties of the protocol, but that has the drawback of not being affected by a socket-binding-group's port-offset. This means that if you want to run 2 WildFly instances on the same box with the same config (which I do, as a developer, to test application code related to clustering), simply changing the port offset is insufficient to get the second instance to start. So I'd like to suggest that socket-binding for FD_SOCK be resurrected, given that it can be implemented correctly now. FD_SOCK calls the configured SocketFactory for both the server socket (with name jgroups.fd_sock.srv_sock) and the client socket (with name jgroups.fd.ping_sock), so it should be possible for WildFly to fully manage the socket bindings. -- This message was sent by Atlassian Jira (v7.12.1#712002)