[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=12991394#comment-12991394 ] 

Richard Achmatowicz edited comment on WFLY-3711 at 8/18/14 2:58 PM:
--------------------------------------------------------------------

There is at least one problem here: the cluster contexts on the client are not getting closed when the last node leaves the cluster. The reason for this is that, at the moment, as initially designed, the closing of the cluster context on the client is only triggered by the sendClusterRemoved message on the server which is in turn triggered by the registryRemoved callback.  The callback action is commented out as removing  a registry from a single node equates to that node leaving the cluster - not that the cluster has no members. Also, topology updates are *not* issued by Infinispan when the last member of a cluster leaves - nor when a first member joins a new cluster, by the way. When a node leaves the cluster, and the registry removed event is triggered, the sendClusterRemoved message should be sent, but should also contain the node which sent the message, so that node may be removed from the cluster context. 

So, the logic for clusterContext closure on the client needs to take this into account.


 


was (Author: rachmato):
There is at least one problem here: the cluster contexts on the client are not getting closed when the last node laves the cluster. The reason for this is that at the moment, as initially designed, the closing of the cluster context on the client is only triggered by the sendClusterRemoved message on the server which is in turn triggered by the registryRemoved callback.  The callback action is commented out as removing  a registry from a single node equates to that node leaving the cluster - not that the cluster has no members. Also, topology updates are not issued by Infinispan when the last member of a cluster leaves It seems the only way to detect the removal of a cluster on the client side is that the set of live connections to cluster nodes has become empty with the removal of the last cluster node. This in turn depends on channel closure working properly.

So, the logic for clusterContext closure on the client needs to take this into account.


 

> 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.2.6#6264)