Prev   Next

Using the Trigger Service (Easy HowTo)

Table of Contents

1. Purpose
2. Prerequisites
3. Introduction
4. Trigger Tutorial
4.1. Trigger Registration Configuration
4.2. Trigger Action Script Configuration
4.3. Start the container
4.4. Create Trigger Registration
4.5. Create Trigger
5. Congratulations!
6. Troubleshooting
6.1. I created a trigger using the mds-trigger-create, but I don't see any triggers when I type mds-trigger-view! Where are the triggers? Why is nothing happening?
6.2. I'm sure the registration was made properly, but the trigger script never fires. OR I followed all of the above steps, but where are the triggers? Why is nothing happening?
6.3. When trying to create the trigger, I get the following error: Error: ; nested exception is: org.apache.commons.httpclient.NoHttpResponseException: The server 127.0.0.1 failed to respond
6.4. General Troubleshooting

1. Purpose

The purpose of this Easy HowTo is to introduce the GT4/MDS4 component known as the Trigger, as well as to provide an example of setting one up successfully. The current GT 4.2-drafts documentation provides a basic reference and will be updated as features are added, but for those of you who would like to get a simple trigger working without going through all of the documentation, this document is for you.

We will be creating a simple trigger from scratch, and setting it up completely. To get the basic idea of how this is done, we will only use elements available in the default GT4 installation to show you how to use triggers.

2. Prerequisites

  • Basic GT4 installation (one of the following):

    • GT 4.1.3+ Installation (including Java WS Core and WS MDS Aggregator Framework).

      [Note]Note

      GT 4.1.3+ is simply a preview to some of the upcoming GT 4.2 functionality. The trigger state is still highly developmental.

  • Basic XML Path Language (XPath)

3. Introduction

Triggers collect information from information providers using the same mechanism as the Index service (within the context of the common aggregator framework); but once that data is collected, we can configure a trigger to perform an action based on that data.

Once the conditions are prepared, and the collected data is evaluated, the data will be compared to the conditions and, if there's a match, the trigger will set an action to occur.

Learning to use triggers involves understanding what you are doing conceptually and knowing how to configure everything properly. Below we'll go through an example trigger configuration file and discuss some steps that should occur in an example setup. Generally when setting up a trigger you should follow the steps outlined in this tutorial.

First let's explain what we are doing. We're going to set up a trigger to monitor the Default Index Service, and we'll use it to act as a function of how many Entries are in the Default Index Service. Based on the number of entries, we can set the trigger to execute an action. When we want an action to occur, our trigger will execute a script that will create a [log] file in our $GLOBUS_LOCATION directory [and every 30 seconds that the new entry is still registered, we'll add a notification to this log file]. This is not necessarily a practical example of how you would use a trigger, but it's simple enough to give you a basic idea of how to set one up. So let's get started!

4. Trigger Tutorial

This tutorial requires a working GT 4.1.3 or higher recent CVS install, or a patched GT 4.1.2 installation.

4.1. Trigger Registration Configuration

The first thing we do is to configure a trigger registration. What this means is that the trigger service will be connected to an aggregator source. The registration tells the trigger service which aggregator source (or, monitored service) it should pay attention to. We can monitor many services at once, but in this example we will be monitoring the Default Index Service. Our trigger registration will specify that we want to be monitoring the Default Index Service. To do this we will specify a Member EPR (or Registrant EPR) in an aggregator configuration file. For this example, we will quickly walk through a new aggregator configuration; this will allow us to register the trigger (The trigger is actually registered once we use the mds-servicegroup-add command; see below).

Let's create the configuration file in the following location (this file is provided with new installs):

$GLOBUS_LOCATION/etc/globus_wsrf_mds_trigger/trigger-registration-example.xml

The entire config file is located further below. The following table breaks it down:

A. Preliminaries
<?xml version="1.0" encoding="UTF-8" ?>
<ServiceGroupRegistrations
    xmlns="http://mds.globus.org/servicegroup/client"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
    xmlns:agg="http://mds.globus.org/aggregator/types">
</ServiceGroupRegistrations>

As this is an XML document, it must be properly formatted XML.

Start your file with the appropriate header.

The ServiceGroupRegistration node is the root of the document.

B. Aggregator Sink / Service Group Registration Information (for more information, go here). 
<?xml version="1.0" encoding="UTF-8" ?>
  <ServiceGroupRegistrations
        xmlns="http://mds.globus.org/servicegroup/client"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
        xmlns:agg="http://mds.globus.org/aggregator/types">
    <defaultServiceGroupEPR>
    </defaultServiceGroupEPR>

  </ServiceGroupRegistrations>

In this section we will enter the Trigger Registration Service.

<?xml version="1.0" encoding="UTF-8" ?>
  <ServiceGroupRegistrations
          xmlns="http://mds.globus.org/servicegroup/client"
          xmlns:xsd="http://www.w3.org/2001/XMLSchema"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
          xmlns:agg="http://mds.globus.org/aggregator/types">
    <defaultServiceGroupEPR>

        <wsa:Address>
          https://127.0.0.1:8444/wsrf/services/TriggerRegistrationService
        </wsa:Address>
    </defaultServiceGroupEPR>
  </ServiceGroupRegistrations>

The Trigger Registration Service will register the monitored service (Member EPR).

C. Aggregator Source Configuration (for more information, go here). 
<?xml version="1.0" encoding="UTF-8" ?>
  <ServiceGroupRegistrations
          xmlns="http://mds.globus.org/servicegroup/client"
          xmlns:xsd="http://www.w3.org/2001/XMLSchema"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
          xmlns:agg="http://mds.globus.org/aggregator/types">
      <defaultServiceGroupEPR>
          <wsa:Address>
          https://127.0.0.1:8444/wsrf/services/TriggerRegistrationService
          </wsa:Address>
      </defaultServiceGroupEPR>

      <ServiceGroupRegistrationParameters>
            xmlns="http://mds.globus.org/servicegroup/client"
            xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
            xmlns:agg="http://mds.globus.org/aggregator/types">
      </ServiceGroupRegistrationParameters>
  </ServiceGroupRegistrations>

Now we will specify the parameters used to register a [monitored] resource (e.g. information provider) to the service group (i.e. our trigger registration service).

...
  <ServiceGroupRegistrationParameters
        xmlns="http://mds.globus.org/servicegroup/client"
        xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
        xmlns:agg="http://mds.globus.org/aggregator/types">
      <RegistrantEPR
        xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
        <wsa:Address>
            https://127.0.0.1:8444/wsrf/services/DefaultIndexService
        </wsa:Address>

      </RegistrantEPR>
  </ServiceGroupRegistrationParameters>
  ...

We will set the RegistrantEPR to the entity (or information provider) to be monitored; in this case, we will be monitoring the DefaultIndexService. Note: We refer often to the Registrant EPR as it's more generic name: Member EPR.


...
<ServiceGroupRegistrationParameters
      xmlns="http://mds.globus.org/servicegroup/client"
      xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
      xmlns:agg="http://mds.globus.org/aggregator/types">
  <RegistrantEPR
      xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
      <wsa:Address>
          https://127.0.0.1:8444/wsrf/services/DefaultIndexService
      </wsa:Address>
  </RegistrantEPR>
  <RefreshIntervalSecs>600</RefreshIntervalSecs>

</ServiceGroupRegistrationParameters>
  ...

Set this to the number of seconds upon which the registration will be renewed (this is to keep the registration from expiring): 600.

"600" means that we'll renew the registration every 10 minutes.

...
<ServiceGroupRegistrationParameters
      xmlns="http://mds.globus.org/servicegroup/client"
      xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
      xmlns:agg="http://mds.globus.org/aggregator/types">
  <RegistrantEPR
      xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
      <wsa:Address>
          https://127.0.0.1:8444/wsrf/services/DefaultIndexService
      </wsa:Address>
  </RegistrantEPR>
  <RefreshIntervalSecs>600</RefreshIntervalSecs>

   <Content xsi:type="agg:AggregatorContent"
              xmlns:agg="http://mds.globus.org/aggregator/types">
        <agg:AggregatorConfig xsi:type="agg:AggregatorConfig">
        </agg:AggregatorConfig>
        <agg:AggregatorData />
   </Content>
</ServiceGroupRegistrationParameters>

  ...

Now we configure aggregator-source-specific configuration parameters.

Note: The AggregatorData element must be present, and it is also an empty element.

...
  <Content xsi:type="agg:AggregatorContent"
          xmlns:agg="http://mds.globus.org/aggregator/types">
    <agg:AggregatorConfig xsi:type="agg:AggregatorConfig">

        <agg:GetResourcePropertyPollType 
                xmlns:wssg="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ServiceGroup-1.2-draft-01.xsd">
            <agg:PollIntervalMillis>30000</agg:PollIntervalMillis>
        </agg:GetResourcePropertyPollType>
    </agg:AggregatorConfig>
    <agg:AggregatorData />

  </Content>
  ...

Set this to how often you'll be polling the information provider for data and refreshing the current information: 30000.

"30000" means that you'll be checking the information provider every 30 seconds. This is not typical! We are only using such a short polling interval so that you can quickly visualize whether or not you've successfully set up this trigger!

The xmlns:wssg attribute should all be in one line.

...
  <Content xsi:type="agg:AggregatorContent"
            xmlns:agg="http://mds.globus.org/aggregator/types">
    <agg:AggregatorConfig xsi:type="agg:AggregatorConfig">
        <agg:GetResourcePropertyPollType 
            xmlns:wssg="http://docs.oasis-open.org/wsrf/2004/06/\
                        wsrf-WS-ServiceGroup-1.2-draft-01.xsd">
            <agg:PollIntervalMillis>120000</agg:PollIntervalMillis>

            <agg:ResourcePropertyName>wssg:Entry</agg:ResourcePropertyName>
        </agg:GetResourcePropertyPollType>
    </agg:AggregatorConfig>
    <agg:AggregatorData />
  </Content>

  ...

Set this to the name of the resource property that the data is accessed by: wssg:Entry.

[The format is rp_namespace:rp_localname]

Let's review the complete configuration file just so you can check that you have included everything properly:

$GLOBUS_LOCATION/etc/globus_wsrf_mds_trigger/trigger-registration-example.xml

<ServiceGroupRegistrations
  xmlns="http://mds.globus.org/servicegroup/client"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
  xmlns:agg="http://mds.globus.org/aggregator/types">
  <defaultServiceGroupEPR>
    <wsa:Address>https://127.0.0.1:8444/wsrf/services/TriggerRegistrationService</wsa:Address>
  </defaultServiceGroupEPR>
  <ServiceGroupRegistrationParameters
    xmlns="http://mds.globus.org/servicegroup/client"
    xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
    xmlns:agg="http://mds.globus.org/aggregator/types">
    <RegistrantEPR
      xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">

      <wsa:Address>https://127.0.0.1:8444/wsrf/services/DefaultIndexService</wsa:Address>
    </RegistrantEPR>
    <RefreshIntervalSecs>600</RefreshIntervalSecs>
    <Content xsi:type="agg:AggregatorContent"
      xmlns:agg="http://mds.globus.org/aggregator/types">
      <agg:AggregatorConfig xsi:type="agg:AggregatorConfig">

        <agg:GetResourcePropertyPollType 
          xmlns:wssg="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ServiceGroup-1.2-draft-01.xsd">
          <agg:PollIntervalMillis>30000</agg:PollIntervalMillis>
          <agg:ResourcePropertyName>wssg:Entry</agg:ResourcePropertyName>
        </agg:GetResourcePropertyPollType>
      </agg:AggregatorConfig>

      <agg:AggregatorData />
    </Content>
  </ServiceGroupRegistrationParameters>
</ServiceGroupRegistrations>

You could simply copy these file contents and change the "127.0.0.1" to your hostname. Great! Now that we've got the configuration file set up, we need to register it with the Trigger Registration Service, so that the Trigger Service knows what to look out for. We'll do this later below.

4.2. Trigger Action Script Configuration

We have the trigger set to execute an action whenever our conditions are met, but we need to determine what those actions will be. What do we want the trigger to do if it's going to fire? We do this by setting up a Trigger Action Script.

Here we write the action script; we'll make it very simple:

#!/bin/sh

DATE=`date`

echo "Trigger Service Entry: $DATE" >> $GLOBUS_LOCATION/trigger_service_base_action_log

cat <<EOF
<?xml version="1.0" encoding="UTF-8"?>
<OurActionScriptOutput>
  <OurDataDetected>true</OurDataDetected>
</OurActionScriptOutput>
EOF

Note: This example script should be provided if your have a recent installation, however if not:

Save this file as: $GLOBUS_LOCATION/libexec/trigger/trigger-action-default.sh

[Important]Important

Be sure that this file is executable! (e.g. chmod u+x trigger-action-default.sh)

4.3. Start the container

Now start the container: (Note: the -p option allows you to specify a port. We have been using 8444 in this example. You may also specify -nosec if you want to ignore security.)

$GLOBUS_LOCATION/bin/globus-start-container -p 8444

You may also need to set up your environment variables, and/or generate a new proxy certificate: 

source $GLOBUS_LOCATION/etc/globus-user-env.sh
$GLOBUS_LOCATION/bin/grid-proxy-init -verify -debug

But before we create the trigger, let's just quickly test how many Entries are being registered by the Index Service. Type the following command in one line:

$GLOBUS_LOCATION/bin/wsrf-query -s https://127.0.0.1:8444/wsrf/services/DefaultIndexService 'count(//*[local-name()="Entry"])'

On our setup we get: 3.

4.4. Create Trigger Registration

The registration step is necessary to connect the information source with the Trigger Registration Service (an aggregator service). We configured this above. This step provides access to the information source data so that the trigger can then make this information available and act on it accordingly.

Once the configurations have been properly set, it's easy to register them with the Trigger Registration Service.

We will create the trigger registration by running mds-servicegroup-add(1) to perform the registrations specified in the configuration file (that we configured above).

Run the following command:

$GLOBUS_LOCATION/bin/mds-servicegroup-add $GLOBUS_LOCATION/etc/globus_wsrf_mds_trigger/trigger-registration-example.xml
[Important]Important

Be sure the above command is on one line.

If everything went well, you should get something like:

Processing configuration file...
INFO: Processed 1 registration entries
INFO: Successfully registered https://127.0.0.1:8444/wsrf/services/DefaultIndexService \
to servicegroup at https://127.0.0.1:8444/wsrf/services/TriggerRegistrationService

4.5. Create Trigger

Now that we have created a trigger registration, and we have a service that will be monitored, we're ready to create the actual trigger whose parameters will indicate what information we will be evaluating against any incoming data. It will also specify and execute the action script that we've created. All trigger creation and management is performed via clients.

In this HowTo, we will be using the command-line clients that are provided with your installation. (There is also a web interface, but setting that up will be discussed in an upcoming HowTo). The web interface is easier to use and more visually appealing than the command-line clients!)

  1. We must configure the [command-line] clients according to your individual setup:

    $GLOBUS_LOCATION/etc/globus_wsrf_mds_trigger/client-config-settings

    This file should already be included in your install. It basically looks like this:

    DefaultServiceAddress: https://127.0.0.1:8444/wsrf/services/

    The most important item to edit is the first line. Be sure that the host service address corresponds to your deployed container. When you start the container a list of service addresses will indicate what you should be using for this parameter.

  2. Now we create the trigger

    $GLOBUS_LOCATION/bin/mds-trigger-create https://127.0.0.1:8444/wsrf/services/DefaultIndexService

    The client should produce output similar to the following:

    MDS4 Trigger Creation Client
  ----------------------------
  
  **     Service URL: https://127.0.0.1:8444/wsrf/services/DefaultIndexService
  
  Checking current monitored services (Trigger Registrations)...
  OK
  --> Trigger has been created.

  3. Test the trigger creation by typing the following command:

    $GLOBUS_LOCATION/bin/mds-trigger-view

    This command should produce output similar to the following:

              MDS4 Trigger View Client
          ------------------------
          
          Monitored Services (Trigger Registrations)
          
          1) /wsrf/services/DefaultIndexService
          
          TriggerID:      955e9d90-61d0-11dc-897d-dc2058e0ce31
          TRIGGER NAME:   Default Trigger Name
          MATCHING RULE:  count(//*[local-name()='Entry'])<1
          ACTION SCRIPT:  trigger-action-default.sh
          TRIGGER STATUS: disabled

    This output tells us that there is one trigger registration (with the DefaultIndexService) and that the trigger we have just created is called "Default Trigger Name", we see the EPR Resource Key which we will refer to as the "Trigger ID" and this TriggerID is required for editing the trigger, we see a Matching Rule (which is an XPath query against the monitored service, or the DefaultIndexService), we see the name of the trigger action script (located in $GLOBUS_LOCATION/libexec/trigger/), and we see that the trigger is DISABLED. This means that the trigger will not fire, nor will it try to evaluate any data. Basically, this is an inactive trigger.

  4. In order to make things happen you must enable the trigger. This is done with the mds-trigger-edit command. The syntax is: 

    mds-trigger-edit [TriggerID] [Parameter="Value"]

    (For a list of possible parameters, see the "Trigger Service Resource Properties" section of the Public Interface Guide)

    $GLOBUS_LOCATION/bin/mds-trigger-edit 955e9d90-61d0-11dc-897d-dc2058e0ce31 TriggerName="NewName"

    This will output something similar to:

    MDS4 Trigger Edit Client
------------------------

Note: currently, only one parameter may be edited at a time.
** Edit Query: TriggerName=NewName

Trigger Parameter: TriggerName
Trigger Parameter Value: NewName

Setting TriggerName to NewName...
Done.

    Changing the name of the trigger is completely up to you. It's not really important except if you're managing tons of triggers. But let's enable this trigger. By enabling/activating the trigger, we turn it "on", meaning that it will take the Matching Rule and evaluate this against incoming aggregator data from our monitored service (the Default Index Service).

    $GLOBUS_LOCATION/bin/mds-trigger-edit 955e9d90-61d0-11dc-897d-dc2058e0ce31 TriggerStatus="enabled"

    When this trigger is "enabled", we now have an active trigger that is actively evaluating data. You may notice this in the service container screen if you're in "debug" mode (You can allow "debug" information by uncommenting: log4j.category.org.globus.mds.trigger=DEBUG in your $GLOBUS_LOCATION/container-log4j.properties file). But our trigger will not fire since the Matching Rule evaluates to false. There is more than one entry in the Default Index Service, so when we use our Matching Rule, a false evaluation will not allow the trigger to fire. So let's change our Matching Rule so that the trigger will evaluate to "true", thus firing the trigger.

    $GLOBUS_LOCATION/bin/mds-trigger-edit 955e9d90-61d0-11dc-897d-dc2058e0ce31 MatchingRule="count(//*[local-name()='Entry'])>1"

    Typing $GLOBUS_LOCATION/bin/mds-trigger-view will basically summarize what we've done:

    Monitored Services (Trigger Registrations)

1) /wsrf/services/DefaultIndexService

TriggerID:      955e9d90-61d0-11dc-897d-dc2058e0ce31
TRIGGER NAME:   New Name
MATCHING RULE:  count(//*[local-name()='Entry'])>1
ACTION SCRIPT:  trigger-action-default.sh
TRIGGER STATUS: enabled

To view more details about this particular trigger, type: 

$GLOBUS_LOCATION/bin/mds-trigger-view 955e9d90-61d0-11dc-897d-dc2058e0ce31

Syntax: mds-trigger-view [TriggerID]

MDS4 Trigger View Client
 ------------------------

----Detailed Trigger Information----------------------------

MONITORED SERVICE:  https://127.0.0.1:8444/wsrf/services/DefaultIndexService
TriggerID:          955e9d90-61d0-11dc-897d-dc2058e0ce31
TRIGGER NAME:       New Name

MATCHING RULE:      count(//*[local-name()='Entry'])>1
ACTION SCRIPT:      trigger-action-default.sh
TRIGGER STATUS:     enabled

ENABLE BOOLEAN:                         true
ACTION SCRIPT INPUT FULL ORIGINAL:      true
ACTION SCRIPT INPUT XPATH QUERY RESULT: true

MINIMUM FIRING INTERVAL: 20
MINIMUM MATCH TIME:      30

START TIME:            N/A
END TIME:              N/A

INVALIDITY START TIME: N/A
INVALIDITY END TIME:   N/A

----Non-editable stats--------------------------------------
RULE LAST CHECKED AT: N/A
CONDITION TRUE SINCE: N/A
ACTION FIRED AT:      N/A
------------------------------------------------------------

Now after a minute or so, you will notice that the trigger has fired successfully. You can verify this by checking the contents of the log file we created in our action script from above:

more $GLOBUS_LOCATION/trigger_service_base_action_log

This should look similar to the following

Trigger Service Entry: Sun Jun 17 14:45:26 CDT 2007
Trigger Service Entry: Sun Jun 17 14:45:56 CDT 2007
Trigger Service Entry: Sun Jun 17 14:46:26 CDT 2007
Trigger Service Entry: Sun Jun 17 14:46:56 CDT 2007

There is a 30 second interval that we specified in our aggregator configuration file above. This should probably be lengthened eventually so that you don't have the triggers going off so often.

5. Congratulations!

You have now successfully setup, configured, registered, created, edited and tested a trigger from scratch!

Next Steps: Check out the documentation and create more triggers to perform actions more relevant to your own objectives. Experiment with the XPath queries to expand the possibilities of what you can use them for. If you have questions, feel free to [contact us]!

Please keep in mind that this is in a highly developmental stage, so there may be errors, or unpredictable behavior. Feel free to let us know what works, what doesn't, and your general experiences with the trigger service.

6. Troubleshooting

6.1. I created a trigger using the mds-trigger-create, but I don't see any triggers when I type mds-trigger-view! Where are the triggers? Why is nothing happening?

Did you set up a trigger registration? (See the Trigger Service Admin Guide) The trigger has been created (unless there was an error), but you will not see it and you cannot access it if the trigger registration has not been set up.

6.2. I'm sure the registration was made properly, but the trigger script never fires. OR I followed all of the above steps, but where are the triggers? Why is nothing happening?

Once you've completed the trigger registration, you can now create individual triggers. Trigger creation is performed using a client. See the User's Guide for more information on clients.

6.3. When trying to create the trigger, I get the following error: Error: ; nested exception is: org.apache.commons.httpclient.NoHttpResponseException: The server 127.0.0.1 failed to respond

...and I get the following error in the container screen:

      2007-08-21T18:49:39,632-05:00 ERROR container.GSIServiceThread [ServiceThread-18,process:117] [JWSCORE-192] Error processing request
      java.io.IOException: Token length 1347375956 > 33554432
      at org.globus.gsi.gssapi.net.impl.GSIGssInputStream.readToken(GSIGssInputStream.java:98)
      at org.globus.gsi.gssapi.net.impl.GSIGssInputStream.readHandshakeToken(GSIGssInputStream.java:59)
      at org.globus.gsi.gssapi.net.impl.GSIGssSocket.readToken(GSIGssSocket.java:65)
      at org.globus.gsi.gssapi.net.GssSocket.authenticateServer(GssSocket.java:127)
      at org.globus.gsi.gssapi.net.GssSocket.startHandshake(GssSocket.java:147)
      at org.globus.gsi.gssapi.net.GssSocket.getOutputStream(GssSocket.java:166)
      at org.globus.wsrf.container.GSIServiceThread.process(GSIServiceThread.java:115)
      at org.globus.wsrf.container.ServiceThread.run(ServiceThread.java:459)

Be sure that you have properly edited the $G_L/etc/globus_wsrf_mds_trigger/client-config-settings file. The "DefaultServiceAddress" parameter should properly reflect the service prefix from your container, e.g.: https://127.0.0.1:8444/wsrf/services/. The services you wish to monitor should also be consistent.

6.4. General Troubleshooting

Because the Trigger Service runs on top of the Java WS Core, general troubleshooting information can be found in Troubleshooting.

Prev   Next
GT 4.1.3 MDS4 Trigger Service: User's Guide Home Command-line tools