JBoss EAP 7.4 brings remote cluster="ejb" instead of remote connector-ref in EJB subsystem
Environment
- Red Hat JBoss Enterprise Application Platform (EAP)
- 7.4
Issue
- Several changes in EJB 3.9 subsystem in EAP 7.4, connectors vs connector-ref why?
- EAP 7.4's
standalone.xml's ejb subsystem brings remote cluster="ejb" but no EAP 7.3. Is this a bug?
Resolution
EAP 7.4 has several changes and it is therefore not backwards (forwards) compatible with EAP 7.3.
Several elements were changes, the subsystem is 3.9 not 3.5. And several other changes were done, including connectors vs connectors-ref, which connector-ref was deprecated and replaced with connectors.
Concerning the attribute "cluster" of the "remote" element. This attribute has existed since EAP 7.0, it defaults to 'ejb', in EAP 7.4 it is not visible in the example EAP configurations to make it more visible. It is only relevant in a clustered scenario - it has no effect for a server in standalone/non-clustered mode. The default value for the attribute is "ejb".
EAP 7.4 (for the time being even standalone.xml files) bring:
<remote cluster="ejb" connectors="http-remoting-connector" thread-pool-name="default">
Root Cause
In the clustered case, it is used to identify the cluster from which topology updates are being sent. This is required when an EJB client is invoking on beans in two or more clusters and we want the client to be able to differentiate between member nodes of each cluster. it is sent as part of the topology update itself and will allow the client to identify ServiceURLs which match a given cluster= affinity constraint which could be used to target beans in a specific cluster. If you want to use two or more clusters, the value of this attribute has to be different for each cluster (and the new names must exist as containers in the Infinispan subsystem).
In the standalone/non-clustered case, topology updates are not sent from the server to the client and so this attribute has no effect. Although having this attribute present in the standalone.xml configuration can be confusing. The non-HA configurations should probably be adjusted to not to specify it explicitly in the configuration of the remote element (although it will still required that its default value be picked up, for the time being at least).
In both standalone and clustered mode, the only constraint is that there must be a cache-container of the same name defined in the infinispan subsystem:
<subsystem xmlns="urn:jboss:domain:infinispan:12.0">
...
<cache-container name="ejb" default-cache="passivation" aliases="sfsb" modules="org.wildfly.clustering.ejb.infinispan"> <!-- here -->
<local-cache name="passivation">
<file-store passivation="true" purge="false"/>
</local-cache>
</cache-container>
...
<subsystem>
This means if one customized the name of the "ejb" cache manager ( EAP
Server Migration Tool
When migrating from EAP 7.2 to EAP 7.4, the cache-container name="ejb" is mandatory in EAP 7.4.
But the migration tool will not add if it was removed. EAP 7.2 will start without it, but EAP 7.4 will not start.
Customization on the name of the "ejb" cache manager (aka cache container) will result in broken migration.
Diagnostic Steps
- See the migration logs, each subsystem should have a "success"
- When migrating from EAP 7.2 to EAP 7.4, the
cache-container name="ejb"is mandatory in EAP 7.4.
Example:
EAP 7.4 default configuration brings:
<subsystem xmlns="urn:jboss:domain:ejb3:9.0">
...
<remote cluster="ejb" connectors="http-remoting-connector" thread-pool-name="default">
<channel-creation-options>
<option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
</channel-creation-options>
</remote>
Whereas a EAP 7.3 configuration brings:
<subsystem xmlns="urn:jboss:domain:ejb3:6.0">
...
<remote connector-ref="http-remoting-connector" thread-pool-name="default">
<channel-creation-options>
<option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
</channel-creation-options>
</remote>
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.