A client-side ClusterContext should reflect the membership of the cluster it represents. This correspondence is maintained by topology updates sent from the server(s) to the client: whenever the cluster topology changes, updates are sent back to the client so that the ClusterContext may be updated.

ClusterRemovalMessageHandler is a handler which gets called on the client side in response to an topology change event on the server side; namely, when a node leaves a cluster. It responds by removing the ClusterContext from the enclosing EJBClientContext. The only problem is that when a node leaves a cluster, it does not mean that the cluster now has zero members; it may simply have one less than before.

Because of this discrepancy, the server-side code which sent the topology update, in the VersionOneChannelProtocolHandler method sendClusterRemovedMessage() has been commented out, so that the message is not sent and we don't erroneously delete the ClusterContext.

But this creates another problem: when the last node of a cluster leaves, the sendClusterRemovedMessage() was the only way to notify the client that the last member has left; Infinispan does not generate @CacheModifiedEvent callbacks when the last member of a cluster leaves. Consequently, the ClusterContext on the client never gets notified that the last member has left the cluster and the ClusterContext stays open, when in fact it should be closed.