Customer is using JBoss EAP on Openshift v3. Customer is using a TCP-based cluster with an initial discovery protocol called openshift.DNS_PING. It seems there is a delay is node discovery with this protocol, as each node initially forms its own cluster and then later merges. Because of the merge, the HTTP sessions created earlier on node1 are not copied to node2 (default functionality in Infinispan). Customer can remedy this behavior by starting up both nodes and allowing them to form a cluster. <subsystem xmlns="urn:jbossomain:jgroups:1.1" default-stack="${jgroups.protocol.stack}"> ... <stack name="openshift-tcp"> <transport type="TCP" socket-binding="jgroups-tcp"/> <protocol type="openshift.DNS_PING"/> <protocol type="MERGE2"/> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/> <protocol type="FD"/> <protocol type="VERIFY_SUSPECT"/> <protocol type="pbcast.NAKACK"/> <protocol type="UNICAST2"/> <protocol type="pbcast.STABLE"/> <protocol type="pbcast.GMS"/> <protocol type="UFC"/> <protocol type="MFC"/> <protocol type="FRAG2"/> <protocol type="RSVP"/> </stack> </subsystem>
(In reply to Ricardo Martinelli de Oliveira from comment #0) > Customer is using JBoss EAP on Openshift v3. Customer is using a TCP-based > cluster with an initial discovery protocol called openshift.DNS_PING. It > seems there is a delay is node discovery with this protocol, as each node > initially forms its own cluster and then later merges. Because of the merge, > the HTTP sessions created earlier on node1 are not copied to node2 (default > functionality in Infinispan). Customer can remedy this behavior by starting > up both nodes and allowing them to form a cluster. > > > <subsystem xmlns="urn:jbossomain:jgroups:1.1" > default-stack="${jgroups.protocol.stack}"> > ... > <stack name="openshift-tcp"> > <transport type="TCP" socket-binding="jgroups-tcp"/> > <protocol type="openshift.DNS_PING"/> > <protocol type="MERGE2"/> > <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/> > <protocol type="FD"/> > <protocol type="VERIFY_SUSPECT"/> > <protocol type="pbcast.NAKACK"/> > <protocol type="UNICAST2"/> > <protocol type="pbcast.STABLE"/> > <protocol type="pbcast.GMS"/> > <protocol type="UFC"/> > <protocol type="MFC"/> > <protocol type="FRAG2"/> > <protocol type="RSVP"/> > </stack> > </subsystem> What I did to reproduce is: * Create a project * Use the eap6-basic-sti template to create an app using a modified jboss-eap-quickstarts/kitchensink to enable clustering * Create a directory under jboss-eap-quickstarts/kitchensink named configuration with a custom standalone-openshift.xml file in it with some specific logging configuration for jgroups What happened: * I can't see in the logs anything about jgroups logging, which makes me feel I didn't follow the correct steps to add a custom configuration * I didn't find in the logs anything related session replication and the cluster being formed, so I don't know even if my environment is running in cluster
xPaaS QE verified this issue as part of the 1.1.0 release of EAP image. You can use the new EAP image jboss-eap-6/eap64-openshift:1.1 to verify the functionality. Also use templates from https://github.com/jboss-openshift/application-templates/tree/ose-v1.1.0 (ose-v1.1.0 tag). During this release the DNS_PING protocol was replaced by KUBE_PING protocol that uses Kubernetes API calls to get list of EAP instances that form the cluster. This way is faster and more reliable than DNS queries.