[
https://issues.jboss.org/browse/WFLY-3711?page=com.atlassian.jira.plugin....
]
Richard Achmatowicz commented on WFLY-3711:
-------------------------------------------
Another problem is that when topology updates arrive, we do not differentiate between
these two types of topology updates:
- an update received from an already connected node which tells us that a new node (or
nodes) have been added to the existing cluster topology
- an update from a newly connected node which represents a full cluster topology )(i.e.
the contents of that nodes Registry entry for the cluster in question)
At the moment, both of these update messages are handled by the same handler
(ClusterTopologyUpdateHandler) which interprets the set of nodes passed as nodes which
have been added to the cluster: the response is to add the nodes to the existing cluster
context. This is different from interpreting the set of nodes passed as the nodes which
make up the current state of the cluster: the correct response here is to make sure that
the cluster context matches this set of nodes (and may require removing nodes which are no
longer members.
What should happen is that the two message types should be differentiated and handled
differently (in the way described above).
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)