[wildfly-dev] Is there a way to avoid multiple singleton masters

[Paul Ferraro]

WFLY-68 adds the ability to specify a quorum required for a singleton service to start, i.e. a partition must have at least Q members in order for a singleton master election to take place.  In general, the quorum value should be int(N/2)+1, where N is the cluster size.  e.g. If your cluster size is 3, it would be advisable to set the quorum size to 2.
You can find an example of building a singleton service with a specified quorum here:
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clust/src/test/java/org/jboss/as/test/clustering/cluster/singleton/service/MyServiceActivator.java

This of course means that any partition that does not have a least Q members will not have a transaction recovery manager until the partition is healed.

----- Original Message -----
> From: "Michael Musgrove" <mmusgrov at redhat.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Wednesday, June 18, 2014 10:12:31 AM
> Subject: [wildfly-dev] Is there a way to avoid multiple singleton masters
> 
> I'd like to have an option of running our transaction recovery manager
> as an HA singleton. WFLY-68 implies that the master can run at most once
> (even in the presences of network partition) but I don't see how we can
> guarantee that. If I hold the service start in a breakpoint then split
> the network and then allow another master on the other side of the
> partition to become master and then release the breakpoint we will
> briefly have two services running. I know using breakpoints is invalid
> but surely there are timing windows where the same outcome could
> conceivably occur.
> 
> Mike
> 
> --
> Michael Musgrove
> Transactions Team
> e: mmusgrov at redhat.com
> t: +44 191 243 0870
> 
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US),
> Michael O'Neill(Ireland)
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>