com.bigdata.service.jini
Class AbstractServer.MasterElectionTask

java.lang.Object
  com.bigdata.service.jini.AbstractServer.MasterElectionTask

All Implemented Interfaces:

Callable

Enclosing class:

AbstractServer

protected class AbstractServer.MasterElectionTask
extends Object
implements Callable

Task runs forever competing to become the master.

Version:

$Id$

Author:

Bryan Thompson

Constructor Summary

AbstractServer.MasterElectionTask()

Method Summary

Object	call() Calls runOnce() until the service is shutdown, logging any errors.
protected void	runAsMaster(AbstractService service, ZLock zlock) Invoked when this service becomes the master.
protected void	runOnce() Competes for the BigdataZooDefs.MASTER_ELECTION ZLock.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

AbstractServer.MasterElectionTask

public AbstractServer.MasterElectionTask()

Method Detail

call

public Object call()
            throws Exception

Calls runOnce() until the service is shutdown, logging any errors.

Specified by:

call in interface Callable

Throws:

Exception

runOnce

protected void runOnce()
                throws Exception,
                       InterruptedException

Competes for the BigdataZooDefs.MASTER_ELECTION ZLock. If it gains the lock, then invoked #runAsMaster().

Throws:

InterruptedException - if interrupted.

Exception - if anything else goes wrong.

runAsMaster

protected void runAsMaster(AbstractService service,
                           ZLock zlock)
                    throws InterruptedException,
                           Exception

Invoked when this service becomes the master. If there is only one physical service instance running for a given logical service, then it should gain the ZLock and run as the master. If there is more than one physical service instance for a given logical service, then they will all compete for the same ZLock. That competition will place them into an order. The order of the services for the lock node is their failover order. The master is always the first service in the queue. If the master dies, then the next surviving service in queue will gain the lock.

Parameters:

service -

zlock -

Throws:

InterruptedException - if interrupted.

Exception - if anything else goes wrong.

TODO:

If someone deletes the master's zlock then the master will notice (if it checks the zlock) and see that it is no longer the master.

In order to prevent two services from running as "masters" at the same time it is important that the master notice that it has lost the lock BEFORE zookeeper clears its ephemeral znode. The clue is the disconnect event from the zookeeper client. That can set a volatile flag that is used to disable the master. A disabled master should immediately cease responding, terminating all outstanding requests., the behavior needs to be delegated to the service. there is no API for that right now. all of this is just stubbed out for the moment.