[jboss-jira] [JBoss JIRA] (WFLY-11807) Better port configuration for JGroups FD_SOCK

[Paul Ferraro (Jira)]

     [ https://issues.jboss.org/browse/WFLY-11807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-11807:
--------------------------------
    Issue Type: Bug  (was: Enhancement)


> Better port configuration for JGroups FD_SOCK
> ---------------------------------------------
>
>                 Key: WFLY-11807
>                 URL: https://issues.jboss.org/browse/WFLY-11807
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 14.0.0.Final
>            Reporter: Rich DiCroce
>            Assignee: Paul Ferraro
>            Priority: Major
>
> 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)