Introduction
The Aggregator Framework allows pluggable data sources and sinks to be written and connected together. Generally a source collects data from or about a particular grid resource, and passes it to a sink which does something interesting with it.
The aggregator sinks supplied with the toolkit implement the Index Service and Trigger Service. The aggregator sources supplied with the toolkit collect information using resource property queries, subscription/notification, and execution of external programs.
This document describes the programmatic interfaces to the Aggregator Framework. See also general Globus Toolkit coding guidelines and GT 4.2.1 best practices.
Table of Contents
- Aggregator How-to
- 1. Before you begin
- 2. Usage scenarios
- 3. Tutorials
- 4. Architecture and design overview for the WS MDS Aggregator Framework
- 5. APIs
- 6. WS and WSDL
- WS MDS Commands
- mds-servicegroup-add - Registering grid resources to aggregating MDS services such as the Index, Archive and Trigger services
- mds-set-multiple-termination-time - Administering the termination time of grid resources created by aggregating MDS services such as the Index and Trigger services
- 7. Configuring execution aggregator source
- 8. Configuring the Aggregator Framework
- 9. Overview of Graphical User Interface
- 10. Debugging
- 11. Troubleshooting
- 12. Related Documentation
- Glossary
- Index
C
- configuring, Configuring the Aggregator Framework
- aggregator sinks, Configuring the Aggregator Sink
- aggregator sources, Configuring the Aggregator Sources
- disabling publishing, Disabling the publishing of the aggregator configuration on the server side
- execution aggregator source, Configuring execution aggregator source
- executable, Configuring the executable
- overview, Configuration overview
- configuring termination time of resources registered to MDS aggregator services, mds-set-multiple-termination-time
- creating WS MDS services, Creating WS MDS services
D
- debugging, Debugging
R
- registering resources to MDS aggregator services, mds-servicegroup-add
T
- troubleshooting
- execution aggregator source, Troubleshooting
Table of Contents
Features new in release GT 4.2.1
- The mds-servicegroup-add command no longer requires the -s or -e arguments
- The mds-set-multiple-termination-time command has been created to aid in lifetime management of service group entry resources created via mds-servicegroup-add
Other Supported Features
- Collects information from grid resources using pluggable aggregation sources which collect information by polling, subscription, and by execution of local scripts.
- Delivers collected information to pluggable information sinks.
- Management of individual aggregations is now performed over the wire through WS ServiceGroup APIs.
- The QueryAggregatorSource and SubscriptionAggregatorSource now attempt to detect when the data source EPR is local to the current container instance, and if so set the connection properties to use local transport.
- Added a service level configuration option for suppressing the publication of aggregator configuration elements in aggregator service group registry entries. In other words, the Service Group "Content" Resource Property will contain only the aggregated data.
The Aggregator framework is completely backward compatible with the version included in GT 4.2.0.
Protocol changes since GT version 4.0
- The Aggregator Framework is affected by the Java WS Core protocol changes (see the Java WS Core Release Notes for details)
API changes since GT version 4.0
- None. Aggregator sources and execution information providers written for GT version 4.0 should continue to work in this version.
Schema changes since GT version 4.0
- See the Java WS Core Release Notes.
Aggregator Framework depends on the following GT components:
- Java WS Core
Aggregator Framework depends on the following 3rd party software:
- None
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.
Table of Contents
The Aggregator Framework is used to create MDS services by linking an aggregator source (a java class that implements the AggregatorSource interface to collect data) to an aggregator sink (a java class that implements the AggregatorSink interface to process data, e.g., by providing a service interface for it). The AggregatorSource and AggregatorSink interfaces are documented in Chapter 5, APIs.
[provide more concrete info/example?]
Use of the index service (based on the WS MDS Aggregator Framework) is covered in the Build a Grid Service Tutorial (GlobusWORLD 2005).
Table of Contents
The WS MDS Aggregator Framework is the software framework on which WS MDS aggregator services are built. The Aggregator Framework collects data from an aggregator source and sends that data to an aggregator sink for processing.
Aggregator sources distributed with the Globus Toolkit include modules that query resource properties, acquire data through subscription/notification, and execute programs to generate data.
Another way of describing the Aggregator Framework is that it is designed to facilitate the collecting of information from or about WS-Resources via plugin aggregator sources and the feeding of that information to plugin aggregator sinks, which can then perform actions such as re-publishing, logging, or archiving the information.
Aggregators work on a type of service group called an
AggregatorServiceGroupRP. Resources may be
registered to an AggregatorServiceGroupRP using the service
group add operation, which will cause an entry to be
added to the service group. The entry will include configuration
parameters for the aggregator source; when the registration is
made, the appropriate aggregation source and sinks will be
informed; the aggregator source will begin collecting data and
inserting it into the corresponding service group entry, and the
aggregator sink will begin processing the information in the
service group entries.
The method of collection by source and processing by the sink is dependent on the particular instantiation of the aggregator framework.
The aggregator sinks distributed with the toolkit
(org.globus.mds.aggregator.impl.ServiceGroupEntryAggregatorSink
and org.globus.mds.trigger.impl.TriggerResource) are
described in the following table.
Table 4.1. Standard aggregator sinks
| Aggregator Sink | Service Implemented | Description |
|---|---|---|
ServiceGroupEntryAggregatorSink | Index Service | The servicegroup sink (used by the Index Service) publishes received data as content in the AggregatingServiceGroup entry used to manage the registration. This data can therefore be retrieved by querying the index for its 'entries' resource property. |
TriggerResource | Trigger Service | The Trigger Service provides an aggregator sink which receives data, applies tests to that data, and if the tests match, runs a specified executable. See the Trigger Service documentation for more information. |
The aggregator sources supplied with the toolkit collect information using resource property queries (query sources), subscription/notification (subscription sources), and execution of external programs (execution sources).
The aggregator sources supplied with the Globus Toolkit are listed in the following table.
Table 4.2. Standard aggregator sources
| Aggregator Source | Description |
|---|---|
| QueryAggregatorSource |
The query source collects information from a registered resource by using WS-Resource Properties polling mechanisms:
Polls are made periodically, with both the period and target Resource Properties specified in the registration message. |
| SubscriptionAggregatorSource | The subscription source collects information from a registered resource using WS-Notification mechanisms. Data is delivered when property values change, rather than periodically. |
| ExecutionAggregatorSource | The execution source collects information about (not necessarily from) a registered resource by execution of a local executable, which is passed as input the identity of the registered resource. Details of the interface between the execution source and local executables are in Chapter 6, Configuring Execution Aggregator Source. |
Table of Contents
The Aggregator Framework module consists of an Aggregating ServiceGroup framework which supports plugins as detailed below, as well as a number of standard plugins.
The aggregating servicegroup framework is designed to facilitate the collecting of information from or about WS-Resources (via plugin aggregator sources) and the feeding of that information to plugin aggregator sinks.
The framework provides for over-the-wire management of the list of registered resources (through a WS-ServiceGroup interface) and a Java API for connecting sources and sinks together.
In general (although this is not a hard requirement), aggregator sinks will be tied into a specific service implementation, while aggregator sources are more independent. (For example, the trigger and index services act as sinks)
A number of standard aggregator sources are provided, which implement the aggregator source API. These provide for collecting information from/about a WS-Resource by:
- WS-ResourceProperties poll operations
- WS-Notification subscription
- Execution of arbitrary executables
See Aggregator Sources Reference for more information about standard aggregator sources for GT 4.2.1.
There are two main Java interfaces in the aggregator framework.
- AggregatorSink - which is implemented by sinks that can receive data from the Aggregator Framework.
- AggregatorSource - which is implemented by sources that can feed data into the Aggregator Framework.
In addition, the AggregatorContent class is used when configuring an aggregator service
programmatically, and to represent the data published in the aggregator's
Entry resource property.
All aggregator classes and interfaces are documented in the
aggregator Java API documentation
Table of Contents
The Aggregator Framework builds on the WS-ServiceGroup and WS-ResourceLifetime specifications. Those specifications should be consulted for details on the syntax of each operation.
Each Aggregator Framework is represented as a WS-ServiceGroup (specifically, an AggregatorServiceGroup).
Resources may be registered to an AggregatorServiceGroup using the
AggregatorServiceGroup Add operation. Each registration will be represented as a
ServiceGroupEntry resource. Resources may beregistered to an
AggregatorServiceGroup using the service group add operation, which
will cause an entry to be added to the service group.
The entry will include configuration parameters for the aggregator source; when the registration is made, the following will happen:
- The appropriate aggregation source and sinks will be informed,
- the aggregator source will begin collecting data and inserting it into the corresponding service group entry,
- and the aggregator sink will begin processing the information in the service group entries.
The method of collection by source and processing by the sink is dependent on the particular instantiation of the aggregator framework (see per-source documentation for source information and per-service documentation for sink information - for example the Index Service and the Trigger Service.)
-
add:This operation is used to register a specified resource with the Aggregator Framework. In addition to the requirements made by the WS-ServiceGroup specification, the Content element of each registration must be an AggregatorContent type, with the AggregatorConfig element containing configuration information specific to each source and sink (documented in the System Administrator's Guide).
Entry:This resource property publishes details of each registered resource, including both an EPR to the resource, the Aggregator Framework configuration information, and data from the sink.RegistrationCount:This resource property publishes registration load information (the total number of registrations since service startup and decaying averages)
The Aggregator Framework throws standard WS-ServiceGroup, WS-ResourceLifetime, and WS-ResourceProperties faults and does not define any new faults of its own.
Other relevant source files are the:
- WSRF service group schema
- WSRF resource lifetime schema
- MDS Usefulrp schema.
Table of Contents
- mds-servicegroup-add - Registering grid resources to aggregating MDS services such as the Index, Archive and Trigger services
- mds-set-multiple-termination-time - Administering the termination time of grid resources created by aggregating MDS services such as the Index and Trigger services
Name
mds-servicegroup-add — Registering grid resources to aggregating MDS services such as the Index, Archive and Trigger services
Synopsis
mds-servicegroup-add
Tool description
mds-servicegroup-add creates a set of registrations to a WS-ServiceGroup and periodically renews those registrations. It is intended primarily for registering grid resources to aggregating MDS services such as the Index and Trigger services.
The tool can be deployed at the aggregating service, at resource services, or at any other location.
This allows registrations to be configured by the administrator of the aggregating service, or by the administrator of resources, by a third party, or by some combination of those.
Registrations are defined in an XML configuration file, which is documented here: Chapter 3, Registering Aggregator Sources.
For an example using an Index Service, see Simple usage for the Index Service.
And remember to note the section on Limitations.
Command syntax
The basic syntax for mds-servicegroup-add is:
mds-servicegroup-add [options] config.xmlwhere:
| -s http(s)://host:port/service-group-address | A URL to the service group against which the mds-servicegroup-add request will be executed. This command line argument is an optional argument, it is only necessary that this URL argument be specified in the case that there are no suitable target service group EPRs present in the configuration file. Any end point references found in the configuration file will automatically override the EPR specified by this argument on the command-line. If this argument is not specified and no suitable service group EPR is present in the configuration file, the target EPR defaults to the DefaultIndexService on the local host using the default TLS port of 8443. |
| -o outputFile | If this argument is specified, mds-servicegroup-add will write the EPRs of all successfully created service group entries from the target resource to this file. This file can then be used as input to the mds-set-multiple-termination-time command. |
| -q seconds | By default, mds-servicegroup-add will continue to run, refreshing the lifetimes for the service group entry resources it creates. Use this option to cause mds-servicegroup-add to terminate itself after the specified number of seconds has elapsed. This can be helpful when using long-lifetime registrations or when updating entry lifetimes via a different mechanism. |
| -a | By default, mds-servicegroup-add will attempt to make an authenticated connection to each service group. This option is used to specify anonymous connections (and to prevent mds-servicegroup-add from failing if you don't have a valid Grid credential). |
| -z auth_type | Specify an authorization type:
|
| config.xml | Path to the registration configuration file (see Chapter 3, Registering Aggregator Sources). The Globus Toolkit distribution includes an example configuration file:
|
The common java client options are also supported.
Registering a resource manually
Prerequisites
You need the following before you register a resource with an Index Service:
![[Note]](/docbook-images/note.gif) | Note |
|---|---|
Beginning with GT 4.0.1, the CAS, RFT and GRAM4 services are automatically registered with the default Index Service. |
- Have a working Index Service, as documented in the Index Service System Administrator's Guide.
- Know the EPR to the resource.
- Know the EPR to the Index Service. This can be seen in the container output at startup of the container on the index host, and will look something like this:
https://myhost:8443/wsrf/services/DefaultIndexService
Simple usage for the Index Service
The simplest way to register resources to an index is to:
- Edit the example configuration file (
$GLOBUS_LOCATION/etc/globus_wsrf_mds_aggregator/example-aggregator-registration.xml), replacing the EPRs in that file with the EPRs for your resources - Run mds-servicegroup-add to perform the registrations specified in that file.
For example, to register to the DefaultIndexService with a modified example-aggregator-registration.xml file, you
could run a command similar to the following:
$GLOBUS_LOCATION/bin/mds-servicegroup-add -s \
https://127.0.0.1:8443/wsrf/services/DefaultIndexService \
$GLOBUS_LOCATION/etc/globus_wsrf_mds_aggregator/example-aggregator-registration.xml
Name
mds-set-multiple-termination-time — Administering the termination time of grid resources created by aggregating MDS services such as the Index and Trigger services
Synopsis
mds-set-multiple-termination-time
Tool description
mds-set-multiple-termination-time sets the termination time of multiple service group entries. It is intended primarily for working with groups of service group entry resources created by aggregating MDS services such as the Index and Trigger services.
The tool can be deployed at the aggregating service, at resource services, or at any other location.
This allows the lifetime of registrations to be configured by the administrator of the aggregating service, or by the administrator of resources, by a third party, or by some combination of those.
Command syntax
The basic syntax for mds-set-multiple-termination-time is:
mds-set-multiple-termination-time [options]
where:
| -i inputFile | file containing an XML array of Endpoint References, such as one output by the mds-servicegroup-add command when used with the -o option. |
| -w delay | integer wait delay in seconds that will be added to the current time at the remote resource to generate the resource termination time. If not specified the termination time by defaults is set to the current time at the remote resource. |
| -n date string | ISO-8601 formatted date string representing an exact date and time, e.g. 2016-06-28T01:06:430Z If not specified the termination time by default is set to the current time at the remote resource. |
The common java client options are also supported.
Table of Contents
The execution aggregation source provides a way to aggregate data (arbitrary XML information) about a registered resource using an arbitrary local executable (such as an external script). The executable will be passed registration information as parameters and is expected to output the gathered data, as detailed below.
A basic example of the use of this API is described in the [fixme ping test example] for the aggregator execution source.
The execution aggregation source will periodically execute an identified executable. The identity of the executable and the frequency with which it is to run are specified in the registration message.
To register resources with the Index Service:
Create a configuration file in XML that specifies registrations. See
$GLOBUS_LOCATION/etc/globus_wsrf_mds_aggregator/example-aggregator-registration.xmlfor several specific examples. The configuration file is described in more detail below.Run mds-servicegroup-add(1) to perform the registrations specified in that configuration file. For example, to register to the DefaultIndexService with a modified example-aggregator-registration.xml file, you could run a command similar to the following:
$GLOBUS_LOCATION/bin/mds-servicegroup-add -s \ https://127.0.0.1:8443/wsrf/services/DefaultIndexService \ $GLOBUS_LOCATION/etc/globus_wsrf_mds_aggregator/example-aggregator-registration.xml
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 aggregator service, on the same host as a member resource, or on any other host(s).
The configuration file consists of an optional
defaultServiceGroupEPR, an optional
defaultRegistrantEPR, and then one or more
ServiceGroupRegistrationParameters blocks,
each of which represents one registration.
You can use the example configuration at $GLOBUS_LOCATION/etc/globus_wsrf_mds_aggregator/example-aggregator-registration.xml,
replacing the EPRs in that file with the EPRs for your resources. It
includes many examples of configurations for GRAM, RFT and other
situations.
The general syntax of the configuration file is:
<?xml version="1.0" encoding="UTF-8" ?>
<ServiceGroupRegistrations
xmlns="http://mds.globus.org/servicegroup/client">
// An optional default service group EPR.
<defaultServiceGroupEPR>
// Default service group EPR
</defaultServiceGroupEPR>
// An optional default registrant EPR.
<defaultRegistrantEPR>
// Default registrant EPR
</defaultRegistrantEPR>
// An optional default security descriptor file.
<defaultSecurityDescriptorFile>
// Path name of default security descriptor file
</defaultSecurityDescriptorFile>
// One or more service group registration blocks:
<ServiceGroupRegistrationParameters>
<ServiceGroupEPR>
// EPR of the service group to register to
</ServiceGroupEPR>
<RegistrantEPR>
// EPR of the entity to be monitored.
</RegistrantEPR>
<InitialTerminationTime>
// Initial termination time
</InitialTerminationTime>
<RefreshIntervalSecs>
// Refresh interval, in seconds
</RefreshIntervalSecs>
<Content type="agg:AggregatorContent">
// Aggregator-source-specific configuration parameters
</Content>
</ServiceGroupRegistrationParameters>
</ServiceGroupRegistrations>
The following table describes the different blocks of the file and any parameters:
Table 7.1. Aggregator configuration parameters
defaultServiceGroupEPR block | Provides a convenient way to register a number of resources
to a single service group -- for example, if you wish to register
several resources to your default VO index, you can specify that
index as the default service group and omit the
ServiceGroupEPR blocks from each
ServiceGroupRegistrationParameters
block. |
defaultRegistrantEPR | Provides a convenient way to register a single resource to
several service groups -- for example, if you wish to register your
local GRAM server to several index servers, you can specify your
GRAM server as the default registrant and omit the
RegistrantEPR blocks from each
ServiceGroupRegistrationParameters
block. |
defaultSecurityDescriptorFile | Simply the path to the security descriptor file. |
ServiceGroupRegistrationParameters | Each ServiceGroupRegistrationParameters
block specifies the parameters used to register a resource to a
service group. The parameters specified in this block are: |
ServiceGroupEPR | The EPR of the service group to register to. This parameter
may be omitted if a defaultServiceGroupEPR
block is specified; in this case, the value of
defaultServiceGroupEPR will be used
instead. |
RegistrantEPR | The EPR of the resource to register. This parameter may be
omitted if a defaultRegistrantEPR block is
specified; in this case, the value of
defaultRegistrantEPR will be used
instead. |
InitialTerminationTime | The initial termination time of this registration (this may
be omitted). If the initial termination time is omitted, then the
mds-servicegroup-add sets
the initial termination time to the current wall time plus 2 times
that of the specified RefreshIntervalSecs
parameter. |
RefreshIntervalSecs | The refresh interval of the registration, in seconds. The mds-servicegroup-add(1) will attempt to refresh the registration according to this interval, by default incrementing the termination time of the registration by 2 times this interval for every successful refresh. If at any point the termination time for the registration expires the registration will be subject to removal within a maximum of 5 minutes. |
Content | Aggregator-source-specific registration parameters. The content blocks for the various aggregator sources are described in detail in the following sections. |
The configuration block for ExecutionAggregatorSource (inside the Content block) looks like this:
<Content xsi:type="agg:AggregatorContent"
xmlns:agg="http://mds.globus.org/aggregator/types">
<agg:AggregatorConfig xsi:type="agg:AggregatorConfig">
<agg:ExecutionPollType>
<agg:PollIntervalMillis>interval_in_ms</agg:PollIntervalMillis>
<agg:ProbeName>dummy_namespace:probe_name</agg:ProbeName>
</agg:ExecutionPollType>
</agg:AggregatorConfig>
<agg:AggregatorData/>
</Content>
where:
PollIntervalMillisThis parameter is the poll refresh period in milliseconds.
ProbeNameThis parameter specifies the name of the probe to run. To configure this name, go to the
jndi-config.xmlfile for the service being configured and make sure anexecutableMappingsparameter maps probe names to executable names.![[Important]](/docbook-images/important.gif)
Important All executables must be in the directory
$GLOBUS_LOCATION/libexec/aggrexecand you should only specify the name of the script/program, without any qualification or path; GT automatically expands the name to$GLOBUS_LOCATION/libexec/aggrexec/.probenameFor example, the file for the MDS Index Service is
$GLOBUS_LOCATION/etc/globus_wsrf_mds_index_jndi-config.xml, and the following code within that file maps the probe nameaggr-testto the executable calledaggregator-exec-test.shand maps the probe namepingexecto the executableexample-ping-exec.<resource name="configuration" type="org.globus.mds.aggregator.impl.AggregatorConfiguration"> <resourceParams> // ... <parameter> <name>executableMappings</name> <value>aggr-test=aggregator-exec-test.sh, pingexec=example-ping-exec</value> </parameter> </resourceParams> </resource>
The executable to run will be
$GLOBUS_LOCATION/libexec/aggrexec/<scriptname>
with scriptname supplied by the ProbeName parameter in the configuration file.
Information about the registration will be supplied as command line parameters and on stdin.
A single command line parameter will be supplied to the executable. This will be the URL from the EPR of the registered service.
Two XML documents will be sent to stdin, in sequence:
- The first document will be the full EPR to the registered service.
- The second document will be the AggregatorConfig block from the registration message (configuration file).
This file describes an example of using the Execution Aggregator Source API.
The example provides basic ping information about a registrant. It is intended for illustrative purposes, rather than real deployment use.
The aggregator framework is used by other services to collect information. In this example, it will be shown how to configure the index service to use the execution aggregator source.
The example script is installed as:
$GLOBUS_LOCATION/etc/globus_wsrf_mds_aggregator/example-ping-exec.
It is necessary to copy this to the directory where the execution source will look
for executables, and ensure that it's executable:
$ cp $GLOBUS_LOCATION/etc/globus_wsrf_mds_aggregator/example-ping-exec \
$GLOBUS_LOCATION/libexec/aggrexec/. $ chmod a+x
$GLOBUS_LOCATION/libexec/aggrexec/example-ping-exec
By default, the index is configured to use a WS-Resource Properties polling mechanism. It is necessary for this example to change the index configuration to use the execution source instead.
This can be achieved using the mds-servicegroup-add tool.
Rather than configuring the client to register with parameters for the Resource Property polling source, parameters for the execution source should be supplied in each registration.
Register both resources that you know exist, and also some non-existent resources.
Start the container hosting the index, start the mds-servicegroup-add tool, then query the contents of the index with:
$ wsrf-query -s http://localhost:8080/wsrf/services/DefaultIndexService '/*'
Each registration should be represented as an Entry resource property value in the
output of wsrf-query; embedded in each entry should be an
$examplePingResult element with the results of ping testing.
If you've properly configured and registered your script for execution but are getting errors from the container because it cannot find the specified script, there are two likely causes.
First, make sure that your script/program is executable and is located in the
$GLOBUS_LOCATION/libexec/aggrexec directory.
When it's specified in the configuration mentioned above, only specify
the name of the script/program, without any qualification or path.
For example, using a ProbeName of
test-script would specify the file
$GLOBUS_LOCATION/libexec/aggrexec/test-script.
Next, make sure that you have correctly created an
executableMappings definition in the appropriate
jndi-config.xml file.
Table of Contents
WS MDS aggregator services (such as MDS Index, MDS Trigger and MDS Archive Tech Preview) inherit their configuration system from the Aggregator Framework module.
The Aggregator Framework does not have its own service -side configuration, although services which are based on the framework have their own service-side configuration options (such as MDS Index and MDS Trigger") which are documented in the per-service documentation.
Registrations to a working Aggregator Framework are configured for the mds-servicegroup-add(1) tool. This tool takes an XML configuration file listing registrations, and causes those registrations to be made.
In general, configuration of aggregator services involves configuring the service to get information from one or more sources in a Grid. The mechanism for doing this is defined by (inherited from) the Aggregator Framework and described in this section.
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 AggregatorConfig xsd:any array is used to specify parameters that are to be passed to the underlying AggregatorSource when the ServiceGroupadd method is invoked. These parameters are generally type-specific to the implementation of the AggregatorSource and/or AggregatorSink being used.
- The AggregatorData xsd:any array is used as the storage location for aggregated data that is the result of message deliveries to the AggregatorSink. Generally, the AggregatorData parameter of the AggregatorContent is not populated when the ServiceGroup add method is invoked, but rather is populated by message delivery from the AggregatorSource.
For detailed information on configuring the three types of aggregator sources provided by the Globus Toolkit, see Aggregator Sources Reference.
An aggregator sink may require sink-specific configuration (for example, the MDS Trigger Service requires sink-specific configuration; the MDS Index Service does not). See the documentation for the specific aggregator service being used for details on sink-specific documentation.
It is now possible to disable the publishing of the aggregator configuration along
with the aggregated data. The following optional parameter can be added to the
AggregatorConfiguration section of the service
jndi-config.xml file:
<parameter>
<name>publishAggregatorConfiguration</name>
<value>false</value> </parameter>By default, this option is disabled and the aggregator configuration information is published.
There is no GUI specifically for the Aggregator Framework. The release contains WebMDS which can be used to display monitoring information in a web browser. Specifically, it can be directed at services based on the Aggregator Framework to display information about resources registered to the Aggregator Framework.
Table of Contents
Log output from WS MDS is a useful tool for debugging issues. Because WS MDS is built on top of Java WS Core, developer debugging is the same as described in Chapter 10, Debugging. For information on sys admin logs, see Chapter 4, Debugging.
The following information applies to Java WS Core and those services built on it.
Logging in the Java WS Core is based on the Jakarta Commons Logging API. Commons Logging provides a consistent interface for instrumenting source code while at the same time allowing the user to plug-in a different logging implementation. Currently we use Log4j as a logging implementation. Log4j uses a separate configuration file to configure itself. Please see Log4j documentation for details on the configuration file format.
Server side logging can be configured in $GLOBUS_LOCATION/container-log4j.properties, when the container is stand alone container. For tomcat level logging, refer to Logging for Tomcat, . The logger log4j.appender.A1 is used for developer logging and by default writes output to the system output. By default it is set for all warnings in the Globus Toolkit package to be displayed.
Additional logging can be enabled for a package by adding a new line to the configuration file. Example:
#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
Client side logging can be configured in $GLOBUS_LOCATION/log4j.properties. The logger log4j.appender.A1 is used for developer logging and by default writes output to the system output. By default it is set for all warnings in the Globus Toolkit package to be displayed.
Table of Contents
For a list of common errors in GT, see Error Codes.
Table 11.1. Java WS Core Errors
| Error Code | Definition | Possible Solutions |
|---|---|---|
Failed to acquire notification consumer home instance from registry | Caused by javax.naming.NameNotFoundException: Name services is not bound in this Context error. | Please see Running client programs from any directory if a client fails with this error. |
The WS-Addressing 'To' request header is missing | This warning is logged by the container if the request did not contain the necessary WS-Addressing headers. The client either did not attempt to send those headers at all or is somehow misconfigured. | If you are using a
Java client and launching it directly using the java executable,
take a look at Appendix B, Running client programs from any directory.
|
java.io.IOException: Token length X > 33554432 | If you see this error in the container log, it usually means you are trying to
connect to HTTPS server using HTTP. For example, the service address specifies
8443 as a port number and
http as the protocol name. | In general, use
8443 port number with the
https protocol, and 8080 port
number with the http protocol. |
java.lang.NoSuchFieldError: DOCUMENT | This error usually indicates a mismatch between the version of Apache Axis that the code was compiled with and the version of Axis that the code is currently running with. | Make sure that the same version of Axis is used at compile time and at runtime. |
org.globus.wsrf. InvalidResourceKeyException: Argument key is null / Resource key
is missing | These errors usually indicate that a resource key was not passed with the request or that an invalid resource key was passed with the request (that is, the element QName of the resource key did not match what the service expected). | Make sure that the EPR used to invoke the service that contains the appropriate resource key. If
you are using some command-line tool make sure
to specify the resource key using the -k option or pass a
complete EPR from a file using the -e option. |
Unable to connect to localhost:xxx | Cannot resolve localhost. The machine's /etc/hosts isn't set up correctly and/or you do not have DNS for these machines. |
There should always be an entry in /etc/hosts (or /etc/hostname/ on Debian)
for localhost in the following format (IP address/fully qualified domain name/short name):
140.221.8.109 cognito.mcs.anl.gov cognito |
org.globus.common.ChainedIOException: Failed to initialize security context | This may indicate that the user's proxy is invalid. | To correct the error, the user must properly initialize the user proxy. See grid-proxy-init for more information on proxy initialization. |
Error: org.xml.sax.SAXException: Unregistered type: class xxx | This may indicate that an Axis generated XML type, defined by the WS RLS XSD, was not properly registered. While all the XML types should get registered upon deployment without intervention by the user, sometimes they do not. | To remedy the situation add a typeMapping to the server-config.wsdd file under globus_wsrf_replicalocation_service.
Use the format shown here. |
No socket factory for 'https' protocol | When a client fails with the following exception: java.io.IOException: No socket factory for 'https' protocol at
org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:179) at
org.apache.axis.transport.http.HTTPSender.writeToSocket(HTTPSender.java:397) at
org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:135)FIXME - it may have happened because... | Add the following to the client: import org.globus.axis.util.Util; ... static { Util.registerTransport(); }
... |
No client transport named 'https' found | When a client fails with the following exception: No client transport named 'https' found at
org.apache.axis.client.AxisClient.invoke(AxisClient.java:170) at
org.apache.axis.client.Call.invokeEngine(Call.java:2726)
The client is most likely loading an incorrect | Ensure that the GT4 installation
directory is listed as the first entry in the CLASSPATH=/usr/local/globus-4.2.0:/foo/bar/others.jar:... If you are seeing this problem in Tomcat, copy the |
ConcurrentModificationException in Tomcat 5.0.x | If the following exception is visible in the Tomcat logs at
startup, it might cause the java.util.ConcurrentModificationException at
java.util.HashMap$HashIterator.nextEntry(HashMap.java:782) at
java.util.HashMap$EntryIterator.next(HashMap.java:824) at
java.util.HashMap.putAllForCreate(HashMap.java:424) at
java.util.HashMap.clone(HashMap.java:656) at
mx4j.server.DefaultMBeanRepository.clone(DefaultMBeanRepository.java:56)
The java.lang.NullPointerException at
org.apache.coyote.tomcat5.CoyoteRequest.setAttribute(CoyoteRequest.java:1472) at
org.apache.coyote.tomcat5.CoyoteRequestFacade.setAttribute(CoyoteRequestFacade.java:351) at
org.globus.tomcat.coyote.valves.HTTPSValve.expose(HTTPSValve.java:99)
These exceptions will prevent the transport security from working properly in Tomcat. | This is a Tomcat bug. Keep restarting Tomcat until it starts
without the
|
java.net.SocketException: Invalid argument or
cannot assign requested address | FIXME - what causes this? | If you see the $ export GLOBUS_OPTIONS="-Djava.net.preferIPv4Stack=true" |
GAR deploy/undeploy fails with container is running error | A GAR file can only be deployed or undeployed locally while the container is off. However, GAR deployment/undeployment might still sometimes fail with this error even if the container is off. This usually happens if the container has crashed or was stopped improperly, preventing the container from cleaning up its state files. | To resolve
this problem, delete any files under the
|
In general, if you want to investigate a problem on your own please see Chapter 10, Debugging for details on how to turn on debugging.
Most of the command line clients have a
-debugoption that will display more detailed error messages, including the error stack traces.Search the mailing lists such as gt-user@globus.org or jwscore-user@globus.org (before posting a message).
If you think you have found a bug please report it in our Bugzilla system. Please include as much as detail about the problem as possible.
Specifications for resource properties, service groups, and subscription/notification are available at http://www.globus.org/wsrf/.
A
- Aggregator Framework
A software framework used to build services that collect and aggregate data. WS MDS Services (such as the Index and Trigger services) are built on the Aggregator Framework, and are sometimes called Aggregator Services.
- aggregator services
Services that are built on the Aggregator Framework, such as the WS MDS Index Service and Trigger Service.
- aggregator source
A Java class that implements an interface (defined as part of the Aggregator Framework) to collect XML-formatted data. WS MDS contains three aggregator sources: the query aggregator source, the subscription aggregator source, and the execution aggregator source.
I
T
- Trigger Service
An aggregator service (in WS MDS) that collects information and compares that data against a set of conditions defined in a configuration file. When a condition is met, or triggered, the specified action takes place (for example, an email is sent to a system administrator when the disk space on a server reaches a threshold).
W
- Web Services Addressing (WSA)
The WS-Addressing specification defines transport-neutral mechanisms to address web services and messages. Specifically, it defines XML elements to identify web service endpoints and to secure end-to-end endpoint identification in messages. See the W3C WS Addressing Working Group for details.
A
- aggregator sources, Standard aggregator sources
- execution, Standard aggregator sources
- configuring, Configuring execution aggregator source
- troubleshooting, Troubleshooting
- query, Standard aggregator sources
- GetMultipleResourcePropertiesPollType, Standard aggregator sources
- GetResourcePropertyPollType, Standard aggregator sources
- QueryResourcePropertiesPollType, Standard aggregator sources
- subscription, Standard aggregator sources
- AggregatorServiceGroup resource properties, WS MDS Aggregator Framework Resource Properties
- apis, APIs
- architecture, Architecture and design overview for the WS MDS Aggregator Framework
C
- compatibility, Backward compatibility summary
- configuration file, registering
- example-aggregator-registration.xml, Registering resources (general)
- parameters, Registering resources (general)
- execution aggregator source, Configuration file: parameters for the execution aggregator source
- configuration interface, Configuring the Aggregator Framework
- aggregator sinks, Configuring the Aggregator Sink
- aggregator sources, Configuring the Aggregator Sources
- disable publishing, Disabling the publishing of the aggregator configuration on the server side
- overview, Configuration overview
D
- debugging, Debugging
- dependencies, Technology dependencies
F
- features, Feature summary
M
- mds-servicegroup-add, mds-servicegroup-add, Registering resources (general)
- mds-set-multiple-termination-time, mds-set-multiple-termination-time
O
- org.globus.mds.aggregator.impl, Standard aggregator sources
P
- platforms, Tested platforms
R
- registering
- ping test example, Ping test example
- related documentation, Related Documentation
- resource properties, AggregatorServiceGroup, WS MDS Aggregator Framework Resource Properties
S
- security considerations, WS MDS Aggregator Services (Index Service and Trigger Service) Security Considerations
- services, WS and WSDL
T
- tutorials
- Build a Grid Service, Tutorials
U
- usage scenarios, Creating WS MDS services
W
- WSDL, WS and WSDL