[jboss-jira] [JBoss JIRA] (WFLY-13132) Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
Richard Achmatowicz (Jira)
issues at jboss.org
Mon Apr 27 16:34:25 EDT 2020
[ https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14061899#comment-14061899 ]
Richard Achmatowicz edited comment on WFLY-13132 at 4/27/20 4:29 PM:
---------------------------------------------------------------------
Any kind of preference for one protocol over another when choosing the target of the invocation would be set in DiscoveryEJBClientInterceptor, as this is where the results of a call to discovery are processed and a final choice of target is made (see doFirstMatchDiscovery(), doAnyDiscovery( ), doClusterDiscovery()). The results of the discovery calls (before processing required to choose the target) will include all URIs over all protocols which satisfy the filter spec.
So some questions:
* is there a need to constrain the protocol used to be consistent across a single client?
** e.g. maybe for use with transactions, all invocations need to arrive at the same port? or for some other added value feature (such as SSO)?
** maybe for performance reasons?
* what happens with legacy versions of EJB client when discovery offers two possible protocols? Is it possible to repeatedly choose a URI which it cannot handle when an EJBReceiver is being selected?
was (Author: rachmato):
Any kind of preference for one protocol over another when choosing the target of the invocation would be set in DiscoveryEJBClientInterceptor, as this is where the results of a call to discovery are processed and a final choice of target is made (see doFirstMatchDiscovery(), doAnyDiscovery( ), doClusterDiscovery()). The results of the discovery calls (before processing required to choose the target) will include all URIs over all protocols which satisfy the filter spec.
So some questions:
- is there a need to constrain the protocol used to be consistent across a single client?
-- e.g. maybe for use with transactions, all invocations need to arrive at the same port? or for some other added value feature (such as SSO)?
-- maybe for performance reasons?
- what happens with legacy versions of EJB client when discovery offers two possible protocols?
> 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