Customizations and Plug-ins

BeStMan2 has ways for sites to customize the behavior and to plug in specialized mass storage systems.

Customized Transfer Protocol Selection Policy

1. User can define transfer selection plugin for BeStMan2.

2. Configuration entries “protocolSelectionPolicy” and “pluginLib”
Each plugin entry must define the class name, jar file name, and the procotol name the policy applies to. Key values are "class", "jarFile" and "name", and they are separated by "&". Multiple plugin entries for different protocols can be defined, and must be seperated by ";". When two or more plugin entries are defined for the same protocol, the last entry will be used.

For example, when two entries are defined for gsiftp and http respectively;
protocolSelectionPolicy=class=plugin.NotRoundRobin1&jarFile=p1.jar&name=gsiftp;class=plugin.NotRoundRobin2&jarFile=p2.jar&name=http

If key "name=" is missing, and there is only one plugin entry, then the policy would be used on all protocols.

Another configuration entry "pluginLib" must be defined to provide the directory where the user defined jar files are located.
e.g. pluginLib=/opt/bestman/lib/plugin

3. Interface implementation
The interface that need to implement is:

package gov.lbl.srm.policy;
public interface ISRMSelectionPolicy {
    public Object getNext();
    public void setItems(Object[] objs);
}

BeStMan2 server uses getNext() to retrieve the next available "host:port" or "host" list. For example, "gsiftp1.mydomain.edu:2811" or "gsiftp1.mydomain.edu" when default port is used.
BeStMan2 server calls the setItems() to supply the list of available selections, if defined by the supportedProtocols entry in the conf file. supportedProtocols is optional, and when it is not defined, setItems() is called with the default value which is the host name where bestman server process is running on. Although setItems() sets the list of transfer server choices, getNext() may have more than what is provided in supportedProtocols, specially when a new transfer server is added to the list.

Sample implementation is following:

public class NotRoundRobin implements gov.lbl.srm.policy.ISRMSelectionPolicy {
   int _count = -1;
   Object[] _itemArray = null;
   public Object getNext() {
       Object result = null;
       if (_itemArray = null) {
           result = _itemArray[0];
       }
       return result;
   }
   public void setItems(Object[] col) {
       _itemArray = col;
       _count = 0;
   }
}

The values of objects are like "host:port" e.g. "bestman.lbl.gov:2811".

Customized MSS Support

User can extend MSS support for BeStman2
Follow the instruction below to write your custom plug-in. Pack it as a jar file.
Assuming that custom mss plug-in is stored in "/my/foo/dir/foo.jar" and your name space is "plugin.my.mss", modify conf/bestman.rc entries as following:

pluginDir=/my/foo/dir
CustodialQualityStorageMB=[0]path=/any/path&type=plugin.my.mss&jarFile=foo.jar&host=msshost.domain.tld&conf=mymss.rc

The keywords for CustodialQualityStorageMB is:

[0]: indicates that no need for BeStMan to keep track of the usage of the plug-in device.
path: is the home path for each usage. This can be left as an empty string if not needed.
type: is the name space of customized mss plug-in
jarFile: is name of the mss plug-in jar file
host: is the host name that the device is on, e.g. archive.nersc.gov
conf: is the configuration file that the plug-in library needs, example: hpss.init.rc

Instructions for extending the MSS plug-in class with BeStMan2
Look at this java file to extend and implement: SRM_MSSIntf.java
If queue support is needed, extend the super class SRM_MSS too. If queue support is not needed, then there is no need to extend SRM_MSS class.
For a plain sample files, look into this file SRM_MSS_TEST.java. This is a plain implementation without extending SRM_MSS.
For extending super class sample, look into this file SRM_MSS_TESTE.java. This is an implementation with extending SRM_MSS classs.
To test the plug-in, see this example Test_MSS_TEST.java