Bug 1253772 - EAP6 Clustering is not working as expected
EAP6 Clustering is not working as expected
Status: CLOSED CURRENTRELEASE
Product: OpenShift Container Platform
Classification: Red Hat
Component: Image (Show other bugs)
3.0.0
Unspecified Unspecified
urgent Severity high
: ---
: ---
Assigned To: kconner
Wang Haoran
: UpcomingRelease
Depends On:
Blocks: 1267746
  Show dependency treegraph
 
Reported: 2015-08-14 12:13 EDT by Ricardo Martinelli de Oliveira
Modified: 2015-11-23 09:43 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-23 09:43:12 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1977263 None None None Never

  None (edit)
Description Ricardo Martinelli de Oliveira 2015-08-14 12:13:04 EDT
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>
Comment 2 Ricardo Martinelli de Oliveira 2015-08-14 12:40:16 EDT
(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
Comment 11 Tomas Schlosser 2015-11-13 02:44:03 EST
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.

Note You need to log in before you can comment on or make changes to this bug.