]
Richard Achmatowicz commented on WFLY-12624:
--------------------------------------------
At present, the default client mapping returns 127.0.0.1/::1 rather than the hostname
"localhost". The proposal here is to change this to return the hostname instead,
avoiding the issue for the default case. This doesn't prevent a user from configuring
IP addresses in user-specified client mappings.
Return hostname instead of IP address when generating default client
mapping
-----------------------------------------------------------------------------
Key: WFLY-12624
URL:
https://issues.jboss.org/browse/WFLY-12624
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 18.0.0.Beta1
Environment: An EJB client application interacting with a cluster of Wildfly
server nodes
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Priority: Major
When an EJB client application interacts with a clustered Wildfly deployment, it receives
topology updates from cluster nodes describing the membership of the cluster.
For each node in the cluster, a set of one or more client mappings is provided to
indicate how the client may connect to the node, if it hasn't already. If the node is
connected to a single network, there will be one client mapping; if the node is
multi-homed and connected to two networks, there will be two client mappings, etc. Client
mappings specify three things: a CIDR representation of the network the client may be on,
a destination hostname or IP address and a destination port.
Client mappings may be generated by default (if none are provided in the server profile)
or may be specified by the user via client mappings defined in the socket binding of the
Remoting connector. For example:
{noformat}
<socket-binding name="remoting" port="1099">
<client-mapping source-network="135.121.1.29/16"
destination-address="135.121.1.29" destination-port="1099"/>
</socketbinding>
{noformat}
When the client mapping information is received by the EJB client application, it is
added to the discovered node registry (DNR) in the Discovery component of the EJB client.
The DNR represents all known information about nodes with which the client can interact
which was received from nodes in one or more clusters.
When an invocation is attempted, the Discovery component uses this information to
generate a set of ServiceURLs which represent candidate targets (i.e. servers containing
the deployment and module the client is invoking on) for the invocation. The Discovery
component uses "an algorithm" to take the information in the DNR (and other
places) and convert that information to a corresponding set of ServiceURLs representing
available targets. The Discovery component will then select one such ServiceURL and
return this as the target for the invocation.
Discovery obtains node information used in the algorithm from various sources: client
mappings associated with cluster nodes, as described above, as well as Remoting endpoints
associated with established connections to nodes. These pieces of information describe at
a minimum a host and a port.
The problem is that "the algorithm" used in Discovery to compute the set of
ServiceURLs treats hostnames and IP addresses as simple strings. So "localhost"
and "127.0.0.1" are treated as different hosts, even though they refer to the
same host. If a mix of hostnames and IP addresses for the same node is received, this
results in an incomplete/incorrect set of ServiceURLs being generated which in turn leads
to incorrect Discovery failures.