GT 4.2.1 Index Service: System Administrator's Guide

For a basic installation, the Index Service itself does not need any configuration changes from default; a default Index Service is available and automatically "registers" with the following GT web services based resources to allow monitoring and discovery: [CAS], [RFT], and [GRAM4] (click the links for information about what data is sent and how to change it).

	Note
	Auto-registration is turned on by default in GT 4.2.1. See the per service links above for information about configuring this capability.

In order for information to appear in the Index Service, the source of that information must be registered to the Index Service. Information sources are registered using tools like mds-servicegroup-add(1). Each registration has a limited lifetime; mds-servicegroup-add should be left running in the background so that it can continue to refresh registrations. Depending on administration preference, it may be run on the same host as the index, on the same host as a member resource, or on any other host(s).

The Index Service is built on Aggregator Framework and can use any Aggregator Sources Reference to collect information. In the most common case, the index service uses the QueryAggregatorSource to gather resource property values from the registered resource using one of the three WS-Resource Properties operations to poll for information; the polling method used depends on the configuration element supplied in the registration content.

Two other aggregator sources are supplied with the distribution: the SubscriptionAggregatorSource, which gathers resource property values through subscription/notification, and the ExecutionAggregatorSource, which executes an external program to gather information.

The aggregation sources used to collect data can be changed from default by editing the aggregatorSources parameter in the JNDI service configuration. See $GLOBUS_LOCATION/etc/globus_wsrf_mds_index/jndi-config.xml:

<resource name="configuration"
             type="org.globus.mds.aggregator.impl.AggregatorConfiguration">
  <resourceParams>
    <parameter>
      <name> factory</name>
      <value>org.globus.wsrf.jndi.BeanFactory</value>
    </parameter>
    <parameter>
      <name>aggregatorSource</name>
      <value>org.globus.mds.aggregator.impl.QueryAggregatorSource 
             org.globus.mds.aggregator.impl.SubscriptionAggregatorSource 
             org.globus.mds.aggregator.impl.ExecutionAggregatorSource
      </value>
    </parameter>
</resourceParams>

This parameter specifies one or more Java classes that may be used to collect data for the Index. By default it is set to use the QueryAggregatorSource, SubscriptionAggregatorSource, and ExecutionAggregatorSource. Details of these standard sources are in the Aggregator Sources Reference.

Configuring an Aggregating Service Group to perform a data aggregation is performed by specifying an AggregatorContent object as the content parameter of a ServiceGroup add method invocation. An AggregatorContent object is composed of two xsd:any arrays: AggregatorConfig and AggregatorData:

The WS MDS Index Service has been tested to work without any additional setup when deployed into Tomcat. Please follow these Deploying into Tomcat to deploy GT4 services into Tomcat.

	Note
	Note: please complete any prerequisite service configuration steps before you deploy into Tomcat.

By default, the aggregator sources do not use authentication credentials -- they retrieve information using anonymous SSL authentication or no authentication at all, and thus retrieve only publicly-available information. If a user or administrator changes that configuration so that a service's aggregator source uses credentials to acquire non-privileged data, then that user or administrator must configure the service's aggregator sink to limit access to authorized users.

The following information applies to Java WS Core and all services built on Java WS Core.

Java WS Core server side has two types of loggers. One logger is used for development logging and by default writes to standard out. The other logger includes system administration information and is CEDPs best practices compliant.

On client side, only developer logging is available and is configured using log4j.properties.

   #for debug level logging from org.globus.package.FooClass 
   log4j.category.org.globus.package.name.FooClass=DEBUG
   #for warnings from org.some.warn.package
   log4j.category.org.some.warn.package=WARN
   

log4j.appender.infoCategory=org.apache.log4j.RollingFileAppender
   log4j.appender.infoCategory.Threshold=INFO
   log4j.appender.infoCategory.File=var/containerLog
   log4j.appender.infoCategory.MaxFileSize=10MB
   log4j.appender.infoCategory.MaxBackupIndex=2

Problem: An index service entry has AggregatorConfig data but an empty AggregatorData entry.

Solution: There is probably something wrong with the registration. For example, a registration that uses the QueryAggregatorSource aggregator source may have any of the following wrong with it:

You can use the standard toolkit resource property query tools (such as wsrf-get-properties) to verify that the remote resource is responding.