1:20 p.m.
[
https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi...
]
Richard Achmatowicz commented on WFLY-13132:
--------------------------------------------
The work for this issue is now basically done for upstream and the PR (in a private
wildflyclustering repo) involves significant refactoring of the relationships between
connectors, client mappings registries and the way in which cluster topology listeners are
set up.
Essentially, for every connector,we have a separate ClusterTopologyRegistrar and set of
client mappings entries. For an incoming connection, when an EJBServerChannel is created,
its ClusterTopologyListener is registered with a ClusterTopologyRegistar based on the port
of the Connection associated with the Channel and as a consequence, that connection will
only receive client mappings relating to the connector it connected to. No need to change
the client.
The issue requires one small change to EJB client library to add a getConnection() method
to the ClusterTopologyListner interface and its implementation by EJBSefverChannel.
Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
-----------------------------------------------------------
Key: WFLY-13132
URL: https://issues.redhat.com/browse/WFLY-13132
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 19.0.0.Beta2
Reporter: Joerg Baesner
Assignee: Richard Achmatowicz
Priority: Major
Labels: downstream_dependency
Attachments: playground.zip
h2. +Issue+
h3. +General Client setup:+
{code:java}
Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY,
"org.wildfly.naming.client.WildFlyInitialContextFactory");
p.put(Context.PROVIDER_URL, {see below});
p.put(Context.SECURITY_PRINCIPAL, USER);
p.put(Context.SECURITY_CREDENTIALS, PWD);
Context context = new InitialContext(p);
{code}
----
h3. +Standard server configuration:+
{code:xml}
<subsystem xmlns="urn:jboss:domain:ejb3:5.0">
...
<remote connector-ref="http-remoting-connector"
thread-pool-name="default">
<channel-creation-options>
<option name="READ_TIMEOUT"
value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
<option name="MAX_OUTBOUND_MESSAGES" value="1234"
type="remoting"/>
</channel-creation-options>
</remote>
...
</subsystem>
...
<subsystem xmlns="urn:jboss:domain:remoting:4.0">
<connector name="remoting-connector"
socket-binding="remoting" security-realm="ApplicationRealm">
<properties>
<property name="SSL_ENABLED" value="false"/>
</properties>
</connector>
<http-connector name="http-remoting-connector"
connector-ref="default" security-realm="ApplicationRealm"/>
</subsystem>
{code}
h5. +invocation from remote client to server with:+
* {{remote://localhost:4447}}
* {{remote+http://localhost:8080}}
h5. +Client side topology update always:+
{noformat}
DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15)
message from node master:app-cluster-node0, registering cluster ejb to node
master:app-cluster-node0
DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15)
message block from master:app-cluster-node0, registering block ::/0 to address
127.0.0.1:8080
DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15)
message from node master:app-cluster-node0, registering cluster ejb to node
master:app-cluster-node1
DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15)
message block from master:app-cluster-node0, registering block ::/0 to address
127.0.0.1:8180
DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8)
message from node master:app-cluster-node0 for module playground-app/playground-app-web
DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8)
message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
{noformat}
----
h3. +Legacy server configuration:+
{code:xml}
<subsystem xmlns="urn:jboss:domain:ejb3:5.0">
...
<remote connector-ref="remoting-connector"
thread-pool-name="default">
<channel-creation-options>
<option name="READ_TIMEOUT"
value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
<option name="MAX_OUTBOUND_MESSAGES" value="1234"
type="remoting"/>
</channel-creation-options>
</remote>
...
</subsystem>
...
<subsystem xmlns="urn:jboss:domain:remoting:4.0">
<connector name="remoting-connector"
socket-binding="remoting" security-realm="ApplicationRealm">
<properties>
<property name="SSL_ENABLED" value="false"/>
</properties>
</connector>
<http-connector name="http-remoting-connector"
connector-ref="default" security-realm="ApplicationRealm"/>
</subsystem>
{code}
h5. +invocation from remote client to server with:+
* {{remote://localhost:4447}}
* {{remote+http://localhost:8080}}
h5. +Client side topology update always:+
{noformat}
DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15)
message from node master:app-cluster-node0, registering cluster ejb to node
master:app-cluster-node0
DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15)
message block from master:app-cluster-node0, registering block ::/0 to address
127.0.0.1:4447
DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15)
message from node master:app-cluster-node0, registering cluster ejb to node
master:app-cluster-node1
DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15)
message block from master:app-cluster-node0, registering block ::/0 to address
127.0.0.1:4547
DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8)
message from node master:app-cluster-node0 for module playground-app/playground-app-web
DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8)
message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
{noformat}
h2. +Conclusion+
Depending on what is configured as {{connector-ref}} in the {{remote}} of the _ejb3_
subsystem the {{CLUSTER_TOPOLOGY}} update is different. From a client perspective it would
be expected that either the {{CLUSTER_TOPOLOGY}} update would _only_ contain destinations
that are applicable for the _connector/protocol_ that has been used, or maybe even _ALL_
available destinations, as the client could potentially run a mix of protocols between
invocations...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
2246
days inactive
2246
days old
0 comments
1 participants
participants (1)
-
Richard Achmatowicz (Jira)