Uploaded image for project: 'Keycloak'
  1. Keycloak
  2. KEYCLOAK-9009

Cluster fails to merge if started simultaneously

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: 4.6.0.Final
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Environment:

      Keycloak 4.6.0 official docker image, AWS ECS cluster

    • Steps to Reproduce:
      Hide

      Configure cluster of 4 Keycloak Docker containers, using standalone-ha.xml. Start all four simultaneously. Watch the logs. The Received cluster messages remain at four separate nodes, rather than merging into one cluster of four nodes.
      Also sometimes happens if you have an existing working cluster, and restart the nodes two at a time waiting for each node to finish startup logging before starting the next two.
      The workaround is to stop all instances. Start one instance and wait for it to finish, then start the remaining three simultaneously.

      Show
      Configure cluster of 4 Keycloak Docker containers, using standalone-ha.xml. Start all four simultaneously. Watch the logs. The Received cluster messages remain at four separate nodes, rather than merging into one cluster of four nodes. Also sometimes happens if you have an existing working cluster, and restart the nodes two at a time waiting for each node to finish startup logging before starting the next two. The workaround is to stop all instances. Start one instance and wait for it to finish, then start the remaining three simultaneously.
    • Docs QE Status:
      NEW
    • QE Status:
      NEW

      Description

      Our Keycloak docker cluster has four instances, clustered using Infinispan as per the standalone-ha.xml. If you start them all simultaneously the "Receive new cluster" logs indicate four separate clusters, each with a single member. They never get merged into the proper single cluster of four members. It seems to be the merging that has changed. The application then fails (we are not using sticky sessions, and each member is ignorant of the sessions on the other members).

      We can only start the cluster by first starting one instance, then when it is running, starting the other three. The logs then indicate the creation of four separate clusters that do get merged into a single cluster of four.

      This is consistent behaviour, and when we revert back to v.4.5.0, the issue goes away.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                juliandavies Julian Davies
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: