HP Integrity NonStop H-Series - Manual (Page 108)

B Singleton service
This appendix briefly explains the way NSASJ implements the cluster wide singleton service. This
feature is often used by applications to run the singleton on only one instance in a highly available
JBoss cluster. The cluster wide singleton service is a JBoss specific feature and is not specified in
the Java EE spec. This feature must not be mistaken for the Singleton Session Bean defined in the
EJB specification.
NOTE: In the rest of the appendix, the term singleton is used as a synonym for cluster wide
singleton.
Singleton service in JBoss
The singleton service implementation relies on a cluster wide Infinispan cache formed among the
nodes of the cluster. This cache is used to determine the node that executes the singleton service.
The features of the cluster wide cache are also used to intimate the other nodes of the failure of
the master node, which results in electing a new master to run the singleton service. Infinispan
internally uses a product named JGroups to form a network cluster of the JBoss nodes. It relies on
JGroups to notify the cache of any changes in the cluster structure. The cache takes appropriate
action upon any change in the cluster constitution. Any changes in the cache trigger action in the
JBoss Application Server, which can lead to an altered behavior in the singleton service.
Singleton service in NSASJ
To understand the singleton service implementation in NSASJ, it is necessary to understand the
limitations of JGroups when used on NonStop.
JGroups’ features are bundled as a set of protocols (for example, TP, PING, NAKACK, UNICAST,
GMS and so on) and each protocol stacks on top of the other. While forming and maintaining a
cluster, each protocol relies on message exchanges with its peers and relies on reliable message
exchanges within a time frame. For fast processing of the messages, JGroups relies on a bunch
(approximately 10) of Java threads to perform the work.
When JGroups library is used to form a cluster in a simple application which itself does not have
a need for large number (which is equal to 25 or more) of threads, it is observed that a cluster
gets formed as in any other platform. But when JGroups is run from within NSASJ, it is observed
that the behavior of JGroups is erratic. The reason for this erratic behavior was traced to the cluster
nodes not receiving messages in a particular time window, and thus leading to inconsistent cluster
formation. This resulted in NSASJ nodes behave as standalones, and thus impacting the behavior
of the singleton service.
The following are some observations when trying to form an NSASJ cluster using JGroups:
•
Initially each node behaves like a standalone and the standalones eventually form a cluster
after about 10-14 minutes.
•
When an instance of NSASJ gets busy processing user requests, it is likely to miss some of
the JGroup messages leading to the breaking of the cluster.
•
Setting the time window for receiving message to a big value (such as 20 seconds compared
to 2 seconds in JBoss) reduces the problem to some extent, but results in increased start up
time.
NOTE: The number 20 is quoted with respect to one of the protocols (TP) in the stack. The
time frame varies for other protocols.
To overcome the drawback of JGroups, NSASJ adopts a different way to select a master in the
cluster. NSASJ queries TS/MP for the processes in its serverclass and then picks one to be the
master. The singleton service then runs on only that one instance.
108 Singleton service