Aaron Brown > perfSONAR_PS-Services-PingER-0.09 > perfSONAR_PS::Services::MP::Scheduler

Download:
perfSONAR_PS-Services-PingER-0.09.tar.gz

Dependencies

Annotate this POD

View/Report Bugs
Module Version: 0.09   Source  

NAME ^

perfSONAR_PS::Services::MP::Scheduler - A module that will implements a very simple scheduler from which MP's can inherit to run tests etc.

DESCRIPTION ^

This module allows a more intelligent method of running tests in a non-periodic fashion. It does this with the configuration of a perfSONAR_PS::Services::MP::Config module that provides a list and configuration of the tests to be run.

This module keeps two data structures of interest: METADATA which contains all the tests indexed by the metadataId, and SCHEDULE which maintains a hash of epoch time of the test with the metadataId (we do not point to the METADATA datastructure directly as we need the id's sometimes.)

SYNOPSIS ^

  # create a new MP that inherits this scheduler
  my $mp = perfSONAR_PS::Schedule::MP::PingER->new( $config );
  
  # set up the schedule with the list of tests and fork off a manager class
  # that will spawn off tests according to a schedule that should be also
  # defined here.
  $mp->init();

API ^

This module exposes the following methods.

new

Create a new MP Scheduler class $conf is ref to hash of configuration settings

schedule

accessor/mutator for the schedule

config

accessor/mutator for the config storing the mp::config::schedule package

init( $handler )

Initiate the mp. This should involve: - setting the configuration defaults to be used - setting up the schedule for the tests (by using a perfSONAR_PS::Services::MP::Config::Schedule - or inherited object) - attaching message handlers for the daemon architecture from $handler - forking off a scheduler to manage the starting of new measurements.

prepareMetadata

prepare the metadata; in this case, we add the relevant tests into the schedule in preparation for run()

parseMetadata

Populates the schedule for tests to be run

needLS( boolean )

is the mp service setup to register with a LS?

registerLS()

actually register the MP service with a LS, ie send some xml of the metadata available form the MP service (ie what tests it can run)

addTestSchedule( $config )

Adds the schedule list of tests from the perfSONAR_PS::MP::Config::Schedule object

getNowTime

Returns the current time in epoch seconds

shiftNextTest()

removes the next test from the schedule

Returns ( $time, $testid ) for the time in epoch seconds $time when test with id $testid should be started. If there is no test defined, returns (undef,undef)

peekNextTest()

Gives the next testid without removing it from the schedule

Returns ( $time, $testid ); where $start is the epoch seconds when the test $testid should start. If there is no next test, then will return (undef, undef);

addNextTest( $time, $testid )

Places the test with id $testid into the schedule to run at time $time.

maxChildren( $number )

accessor/mutator for the number of max child threads/processes

run()

Forks off a new instance that will act as a manager/boss class for the scheduling and forking off of new measurements.

__run( )

Starts an endless loop scheduling and running tests as defined in $self->{'STORE'} until the program is terminated.

blockInterrupts

block signal interruption

unblockInterrupts

allow interrupts to do as they did

waitForNextTest( )

Blocking function that sleeps until the next test. Problem is that ipc can cause the sleep to exit for any signal. Therefore, some cleverness in determine the actual slept time is required.

doTest( $pid, $testid )

Spawns off a forked instance in order to run the test with id $testid. It will create a perfSONAR_PS::MP::Agent class that will actuall deal with the running of the test and collation of the results.

The forked instance will also deal with the storage defintions by calling the $self->storeData() method which should be overridden by inheriting classes to store the output of the $agent into an MA.

Forked instance will exit at the end of the test. Success and or failure is not propogated back up the stack.

getAgent( $test )

Returns the relevant perfSONAR_PS::MP::Agent class to use for the test. As this class should be inherieted, this method should be overridden to return the appropraote agent to use for the hash $test that contains the parameters for the test.

storeData( $agent, $testid )

Does the relevant storage of data collected from the $agent for the test id $testid.

SEE ALSO ^

perfSONAR_PS::Services::Config::Schedule, perfSONAR_PS::Services::MP::Agent::Base, perfSONAR_PS::Services::Base,

To join the 'perfSONAR-PS' mailing list, please visit:

  https://mail.internet2.edu/wws/info/i2-perfsonar

The perfSONAR-PS subversion repository is located at:

  https://svn.internet2.edu/svn/perfSONAR-PS 

Questions and comments can be directed to the author, or the mailing list.

VERSION ^

$Id: Base.pm 524 2007-09-05 17:35:50Z aaron $

AUTHOR ^

Yee-Ting Li, ytl@slac.stanford.edu

LICENSE ^

You should have received a copy of the Internet2 Intellectual Property Framework along with this software. If not, see <http://www.internet2.edu/membership/ip.html>

COPYRIGHT ^

Copyright (c) 2004-2007, Internet2 and the University of Delaware

All rights reserved.

syntax highlighting: