[jboss-jira] [JBoss JIRA] (WFLY-3711) Topology updates of EJBClient ClusterContexts not being processed correctly after failover

[Richard Achmatowicz (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12996473#comment-12996473 ] 

Richard Achmatowicz commented on WFLY-3711:
-------------------------------------------

There were three problems described here:
- cluster contexts not getting closed on client
- unnecessary ClusterNodeManagers being created as a result of cluster topology updates
- no differentiation between cluster topology message types

The first issue is addressed by the PR attached to this issue (6643)
The second problem is addressed by EJBCLIENT-110.

The third issue is one which requires protocol changes, and it may be that such changes are not absolutely necessary. Cluster topology updates arriving at an EJBCLient may be sent directly, and contain full cluster topologies, or via gossip, and contain only changes to the cluster topology. Direct receipt examples include when a node joins a cluster and the node immediately sends a full cluster topology update to the client, if it is connected. Another example is when a client connects to a node: a full topology update is again sent at that time to the client. On the other hand, indirect or gossip information is received from members of the same cluster who just note which (other) nodes have just joined or left the cluster; in other words, the changes or delta of the topology.. Despite the fact that delta updates and complete topology updates are not differentiated (and they almost certainly should be), it looks very much as though the current implementation will eventually end up with the same ClusterContext membership.

 

> Topology updates of EJBClient ClusterContexts not being processed correctly after failover
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3711
>                 URL: https://issues.jboss.org/browse/WFLY-3711
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 9.0.0.Beta1
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> ClusterContexts are used by EJBClient to keep track of the current set of nodes in a cluster, so that if an EJBClient invocation fails on one node, it may failover to another node in the same cluster. The ClusterContext is made up of ClusterNodeManagers which are responsible for setting up the connections between the EJBClient and the nodes in the cluster.
> Cluster topology updates are sent to registered EJBClients whenever the cluster topology changes (nodes join, nodes leave a cluster). Thse topology updates are processed on the client side by ClusterTopologyUpdateHandler and are used to update the current contents of the associated ClusterContext held on the client.
> The current implementation of the handling of topology updates does not correctly handle the addition/removal of ClusterNodeManagers from the cluster context - namely, rather than check whether or not a new ClusterNodeManager really needs to be added, ClusterNodeManagers are added for every node in the received topology update, leading to many unnecessary EJBReceivers and their channels being created.
> The logs show that up to 18 cluster node manager instances may be created, have their EJBReceivers registered and channels to the remote node created, when only one node has been added to the cluster.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)