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

[Michael Musgrove]

Thanks Paul.

I would also like to know how we can guarantee at most once semantics 
given the scenario I described whereby two masters could be elected in 
the event of a network partition. And isn't there also a window where 
the network partitions with the old master running on the minority side 
and a new master is elected on the majority side before old master is 
stopped - how do you handle the race.

Mike
> 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
>>


-- 
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)