3:01 p.m.
[
https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi...
]
Richard Achmatowicz commented on WFLY-13132:
--------------------------------------------
A test case TwoConnectorsEJBFailoverTestCase has been written which tests use of legacy
"remote" protocol when both connectors have been initialised.
After the test case is run, looking at the server logs, I can see that client mappings for
both remote://localhost:4447 and remote+http://localhost:8080 are getting passed back to
the client:
{noformat}
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received
CLUSTER_TOPOLOGY(15) message from node node-1, registering cluster ejb to node node-1
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received
CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address
localhost:4447
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received
CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address
localhost:8080
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received
CLUSTER_TOPOLOGY(15) message from node node-1, registering cluster ejb to node node-2
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received
CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address
localhost:4547
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received
CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address
localhost:8180
{noformat}
However, what I can also see is that invocations may start off using the legacy protocol
(remote) on port 4447 and then switch over to the HTTP Upgrade protocol (remote+http) at
port 8080 at a later time. This will require further investigation but this makes sense:
we use the proxy affinity to constrain the nodes chosen as targets of the invocation, in
other words, when we want the invocation to go, but we don't constrain the protocol we
use to get there.
So, when discovery looks for a target which satisfies strong =
ClusterAffinity("ejb") and weak = NodeAffinity("node-1"), it searches
through the Discovered Node Registry and finds two entries: one for
remote://localhost:4447 and one for remote+http://localhost:8080. So we may need to add
some logic to force the choice of protocol. Have to look into this in more detail.
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)
2204
days inactive
2204
days old
0 comments
1 participants
participants (1)
-
Richard Achmatowicz (Jira)