Worker pool example

The following is liberally adapted from the skeleton application's IManagerLifeCycle plugin and shows how a manager uses a worker pool. We discuss it after:

public class LifeCyclePlugin extends AbstractPlugin implements IManagerLifeCycle, IPlugin
{
    static final String WORKER_POOL = "worker_pool_1";

    IWorkerPool workerPool()
    {
        return (IWorkerPool)pluginManager().lookup(WORKER_POOL, IWorkerPool.class)[0];
    }
    
    /** Start the plugin. Make sure 2-4 workers are always running. */

    public boolean init(IPluginManager plugin_manager, Object data)
    {
        if (!super.init(plugin_manager, data))
        {
            return false;
        }

        try
        {
            pluginManager().add(WORKER_POOL, WorkerPool.class, null, false);

            IWorkerPool wp = workerPool();
            wp.setRedundancyMin(2);
            wp.setRedundancyMax(4);
            wp.setWorkerType(WORKER_POOL);
        
            wp.add(InternalFacetCache.class, false);
            wp.add(SkeletonWorkerManager.class, false);

            // The file system locator ensures the worker will have
            // 1024kB of disk space. The socket factory locator ensures
            // the worker will have networking.

            FileSystemLocator.LocatorInfo info
                = new FileSystemLocator.LocatorInfo(1024, 1024, true, 1, "disk", 5);
            wp.add("disk", FileSystemLocator.class, info, false);
            wp.add(SocketFactoryLocator.class, false);

            // ...Other plugin work omitted
        }
        catch(Exception e)
        {
            Debug.exc(this, e, "Initialise failed");
            return false;
        }
               
        return true;
    }

    public Warrant coldStart(IPropertyCollection args) throws BeatrixException
    {
        changeLeaderMode(true);
        return managerSupport().getWarrant("admin",null);
    }

    public void changeLeaderMode(boolean you_are_leader)
    {
        IWorkerPool wp = workerPool();

        if (you_are_leader)
        {
            ILeaderSupport ls = (ILeaderSupport)pluginManager()
                .lookup(ILeaderSupport.class)[0];
            ls.setRedundancy(2,4);

            wp.start(false);
        }
        else
        {
            wp.stop(false);
        }
    }

    // ...Lots of other work omitted
}

• Although all this work takes place in the IManagerLifeCycle plugin this doesn't have to be the case. Worker pools can be dealt with anywhere within a manager.
• Any manager can construct worker pools. In this example all managers set them up, but we ensure only the leader activates them. That means any manager is capable of taking over the running of them, but only one manager (the leader) is actually organising the workers at any one time. This helps avoid confusion.
• The worker pool set up takes place in the init() method, so it's called when the manager starts.
• When we add the worker pool plugin we give it a name, worker_pool_1. This is entirely for our own benefit, so we can reference it again easily, and in no way relevant to the worker pool itself.
• By setting the redundancy levels we ensure that when the pool does its periodic checks it will kill or create extra netlets as appropriate.
• By setting the worker type we give this pool its own unique label. When a worker-started or worker-died event comes in the worker pool plugin can see if it came from one of its own workers by looking at its label. We have set the label to be the same as the plugin's label but this is not necessary in general.
• We add four plugins to the worker pool.
  • The SkeletonWorkerManager plugin implements IWorkerResourceRequester and IWorkerLifeCycle. Hence it both decides what resources the workers need, and responds to their life cycle events.
  • The InternalFacetCache plugin is a tool used by the SkeletonWorkerManager.
  • The FileSystemLocator implements IResourceRequester, so the WorkerPool will ask it for workers' resource requirements. It is configured to demand 1024kB of non-redundant disk space.
  • The SocketFactoryLocator also implements IResourceRequester, so it is also asked for resource requirements. (However, it doesn't seek any in this example; see Section  for more on resources in general and this example in particular.)
• The IManagerLifeCycle.coldStart() method is only called after the plugin is initialised. Hence the worker pool is already set up by the time it is called and when changeLeaderMode() is called. The managerSupport() method belongs to our superclass, AbstractPlugin, and just returns this Manager object's IManagerSupport plugin. We have omitted the warmStart() and join() methods.
• The changeLeaderMode() method ensures only the current leader's worker pool is actively monitoring the workers. The start(false) call means the leader's pool is started, but workers start up in their own time; it does not not force an immediate check of the workers. The stop(false) call means the non-leader's pool stops monitoring the workers but they carry on running--for the leader to monitor.