Model change in EJB remote service causes regression

In the issue https://issues.redhat.com/browse/WFLY-13132, support was added to allow multiple connectors on a server to receive and process EJB client invocations. This issue relates to a server configuration issue in the Remoting and EJB3 subsystems which may arise.

Previously, only one Remoting connector could be configured to receive EJB client invocations and that connector had to be specified in the connector-ref attribute of the <remote/> element in the EJB3 subsystem. Now, multiple connectors which support remote EJB client invocations may be used and need to be listed in the connectors attribute of the <remote/> element.

As background, the effect of adding a connector to the connectors (previously connector-ref) attribute is to:

• set up a connector-specific client mappings registry to provide client mappings entries for that connector, which will be used to populate the cluster topology updates sent back to the client when the server is running in HA mode
• set up a connector-specific ClusterTopologyRegistrar to be available to register incoming connections on that connector, to ensure that the correct topology updates do get back to the client, at the initial connection time and at the time of cluster membership changes.

As a general rule, when running in HA mode, all connectors which support EJB client protocols (remote, remote+http) must be listed in the connectors list so that they send the correct cluster topology updates back to the client, reflecting the current state of the cluster. If this is not the case, then the client will not receive the cluster topology updates required for correct HA operation of EJB client invocations on that connector.

However, when running in non-HA mode, the only requirement of the connector is to send an initial cluster topology update message (containing an empty list of cluster topology updates) back to the client upon connection. This is because from a cluster topology update point of view, the node does not belong to a cluster whose membership can ever change. So it is sufficient to send a single initial update with an empty list of clusters to satisfy the requirements of the EJB client to receive an initial topology update on connection to the server.

That is the background to this issue. Now on to the configuration problem.

In versions of Wildfly using connector-ref attribute (where there was only a single ClusterTopologyRegistrar and a single client mappings registry), clients which connected to connectors other than those listed in connector-ref would be provided with the same ClusterTopologyRegistrar. This resulted in the following:

• in the HA case, this would lead to incorrect behavior (connectors not referenced in connector-ref would receive the same topology updates as the connector referenced in connector-ref, with incorrect port values)
• in the non-HA case, this would result in correct behavior; the cluster topology update provider would send back an empty list of cluster topology updates to the client, whether the connector was referenced in connector-ref or not

Consequently, adding connectors to receive EJB client requests with no additional configuration would work correctly.

In versions of Wildfly using the connectors attribute (where each connector referenced there gets its own cluster topology update provider), connectors not referenced in the connectors attribute do not allocate a client mappings registry and do not get assigned a ClusterTopologyRegistrar. This means that adding a connector to the Remoting subsystem which is not also listed in the connectors attribute will not behave correctly, neither in the HA case nor the HA case. At the moment, this leads to a client which hangs upon connection to the server.

One way to solve this problem is to always add any new connectors which are to process EJB client invocations to the connectors attribute of the <remote/> element. This would ensure that every connector had a ClusterTopologyRegistrar which would "do the right thing". But thiswould break legacy behaviour.

Another way to solve this problem is to create a DefaultClusterTopologyRegistrar to handle connectors which are not listed in the connectors attribute. The purpose of this connector would be:

• in the HA case, to issue a warning (or error) message to the log as this is a case of incorrect HA server configuration (as mentioned above)
• in the non-HA case, to ensure that the initial topology update was sent back to the client (as mentioned above)

The second solution would preserve legacy behavior (i.e. we can add connectors in non-HA mode without additional configuration) as well as give a warning / error when connectors are not correctly configured as mentioned above.