[jboss-jira] [JBoss JIRA] (WFLY-13132) Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
Richard Achmatowicz (Jira)
issues at jboss.org
Fri Apr 24 16:01:56 EDT 2020
[ https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056629#comment-14056629 ]
Richard Achmatowicz edited comment on WFLY-13132 at 4/24/20 3:59 PM:
---------------------------------------------------------------------
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, where 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.
was (Author: rachmato):
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)
More information about the jboss-jira
mailing list