• SenseiGMNS usage
• Sensei's configuration values
• Showing the configuration (GUI)
• Logging (includes tracing)

SenseiGMNS, as explained on its own section, specifies the functionality to create or extend subgroups.

It includes two parts: a utility where the client must supply the reference of other group member to join its group, and a directory service. With the directory service, clients just specify the name of a group, and the server takes care of finding other member to perform the join.

To use the utility, it is not needed to execute the GMNS server: the scripts gmns.sh or gmns.bat are used to start the directory server.

The directory server is a replicated application: it should be running on every host where a group is to be existing, although this is not required. As a matter of fact, it is enough to run the directory server on one host, but should this host fall down, no members would be able to join or create new groups!!!

To execute the GMNS server on several hosts, it is important to specify right configuration values; the important values, (all the GMNS configuration values are explained below) are those that specify the references to other GMNSs.

Each GMNS must publish itself; it can use a URL, or a TCP/IP port. In the first case, it must supply a valid file on the configuration value GMNS.referenceFile. In the second case, the port to be used (is always published on the host where it is executed), must be specified on the configuration value GMNS.referencePort.

For example, a GMNS running on the host 201.23.23.1 which wants to be accessed on the port 12500, should specify GMNS.referencePort=12500

Other GMNS's configuration file must now be able to give the localization of the previous GMNS. To do it, it must first specify, using the configuration value GMNS.hosts, the number of available GMNS servers. For each of these GMNSs, it must be specified, or their TCP/IP socket, or their URL. Following the same example, it could give the values shown below:
GMNS.hosts=1
GMNS.hostSocket.1=201.23.23.1:12500

If a server is reachable via a URL, instead of using GMNS.hostSocket.xxx, the configuration property is GMNS.hostURL.xxx, like, for example: GMNS.hostURL.4=http://grasia.fdi.ucm.es/sensei/example/gmns.1

Sensei is configured on a single properties file, which contains values for all the subsystems (GMS, GMNS, also logging values for debugging purposes). The table of properties, together with the default values, is explained below. Note that all the distributions come with a configuration file with default values, located in the scripts (or scripts.win) directory.

Important: Sensei tries by default to open a file called Sensei.properties, which can be located in any of the following places:

• Current directory: directory where the program using sensei is started.
• User's home directory.
• Java's home directory.

If no configuration file is found, Sensei will use default values.

Nevertheless, any application can force Sensei to use a different file. For example, most of the examples (and GMNS itself) support this configuration file through an argument on the command line, usually called conf or config, that must be used like:
gmns.sh -conf=/local/specificGMNSconf.sensei

Sensei is distributed with a GUI to show the configuration values, although is not possible to edit them with this program. The class to be invoked is sensei.util.SenseiConf, which admits as argument the file to show; if no arguments are specified, it shows the sensei properties file found (by default, the file called Sensei.properties in the current directory, or in the user's home directory or in Java's home directory), or, if not found, just the default values.

There is as well a script that can be invoked (it just calls the previous class):

Linux: senseiConf.sh [file]

Windows:senseiConf [file]

The GUI has an appearance like:

To develop Sensei without debugging utilities would have been plain impossible. It is a distributed application where the parts are in continuous communication. The better approach to debug errors, some times difficult to reproduce, has been the logging of the code. With this purpose, every method contains at its beginning a line of code to trace its execution. Obviosly, this approach imposes a big performance penalty, and this tracing is removed on the optimized libraries.

In addition to this automatic code tracing, Sensei includes some tracing associated to the algorithm used, to highlight in an easier way some important events.

Sensei is a project started in 2000, when the JDK 1.4 and its new logging functionality was still not ready. It includes therefore some classes, located in the package sensei.util.logging to cover this functionality.

These classes support two type of logging:

• Locally, on the same Java Virtual Machine that processes the Sensei application. This mode is used when remoteLoggingPort has a value 0 on the configuration file. The main drawback is that, should the JVM block or fall down (as it usually happened on the first iterations), the logging could be lost (and in circustances where this logging would be specially useful).
• Remotely, on a different Java Virtual Machine that must still reside on the same host. In this case, there must be a Logging server installed on a specific port, and this port specified in the configuration value remoteLoggingPort.
  The logging server can be started with:

  Linux: senseiLogger.sh port

  Windows: senseiLogger port