Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-20755

Request for Support: CLUSTER_TOPOLOGY_NODE_REMOVAL Behavior Difference Between WildFly 22 and 31

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • Clustering
    • ---
    • ---

      Request for Support: CLUSTER_TOPOLOGY_NODE_REMOVAL Behavior Difference Between WildFly 22 and 31

       

      Dear WildFly Team,

      We would like to request your support and clarification regarding the behavior difference we’ve observed between two versions of the WildFly clustering libraries:

       

       Background

      In WildFly 31, the wildfly-clustering-server-infinispan-31.0.1.Final.jar listens for notifications from the Infinispan library. Based on our investigation, Infinispan only sends a TopologyChanged event when a node leaves the cluster.

      In contrast, WildFly 22, using wildfly-clustering-server-22.0.1.Final.jar, listens to DataRehashed events instead, and therefore does not react to a node leaving the cluster by sending a CLUSTER_TOPOLOGY_NODE_REMOVAL message.

       


       

      Observed Behavior

      WildFly Version Library Event Listened Result
      31 wildfly-clustering-server-infinispan-31.0.1.Final TopologyChanged GUI logs out when a non-master node interface goes down
      22 wildfly-clustering-server-22.0.1.Final DataRehashed GUI does not log out in the same scenario

       

      This behavioral difference leads to inconsistent cluster event handling, especially when an application server (not the master) experiences a network interface down event.

       


       

      Request

      We would like the WildFly team to:

      1. Confirm this difference in cluster event handling between WildFly 22 and 31.
      1. Clarify whether this change is intentional or an unintended side effect of switching from DataRehashed to TopologyChanged in the newer clustering implementation.
      1. Advise whether there is a recommended solution or workaround to unify or align the behavior across versions.

       

      We appreciate your support and look forward to your guidance on how best to handle this use case.

      Best regards,

       

              pferraro@redhat.com Paul Ferraro
              jamesle123 Viet Le (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: