Adding FD_SOCK2 -> FD_SOCK workaround

[ahus1]

Closes #439

[ryanemerson]

LGTM. I don't have sufficient permissions to merge though.

[kami619]

@ryanemerson were you able to give it a local test ? I can merge the PR if it worked for you.

[ryanemerson]

I did and the cluster formed as expected. I just double checked the logs though and ISPN000901 is still present, so hold off merging and I will investigate if this workaround for 21830 works on a standalone Infinispan instance.

[ahus1]

@ryanemerson - I debugged it and found that in DNS_PING the correct query hostname is present. I assume this happens when it evalues the parent stack.

If you want to enable debugging, add the following to the Keycloak CR:

  additionalOptions:
    - name: log-level
      value: "INFO,org.jgroups:debug"

[ryanemerson]

I debugged it and found that in DNS_PING the correct query hostname is present. I assume this happens when it evalues the parent stack.

We're still getting the ISPN000901 warning because the Infinispan parser is processing both the "kubernetes" and the "kubernetes-with-fdsock" stacks. We could workaround this by extending the "tcp" stack instead, but as it's just a warning I don't think it's worth the hassle. I think we should remove DNS_PING from the "kubernetes-with-fdsock" stack as it's not removing the warning. We can then just wait on the actual fix in the Keycloak operator, as this doesn't affect functionality.

The FD_SOCK changes LGTM.

[mhajas]

This PR is trying to address an issue with state transfer, is the issue caused by a different problem than: keycloak/keycloak#21256

[ryanemerson]

This PR is trying to address an issue with state transfer, is the issue caused by a different problem than: keycloak/keycloak#21256

Yes, this fixes an issue with FD_SOCK2 at the JGroups level keycloak/keycloak#21092

[ahus1]

Merged as of @ryanemerson's review.