/ 
Helios-2.30_5272
River stage one • 5 direct dependents • 5 total dependents
/ Helios::Service

NAME

Helios::Service - base class for services in the Helios job processing system

DESCRIPTION

Helios::Service is the base class for all services intended to be run by the Helios parallel job processing system. It handles the underlying TheSchwartz job queue system and provides additional methods to handle configuration, job argument parsing, logging, and other functions.

A Helios::Service subclass must implement only one method: the run() method. The run() method will be passed a Helios::Job object representing the job to performed. The run() method should mark the job as completed successfully, failed, or permanently failed (by calling completedJob(), failedJob(), or failedJobPermanent(), respectively) before it ends.

TheSchwartz HANDLING METHODS

The following 3 methods are used by the underlying TheSchwartz job queuing system to determine what work is to be performed and, a job fails, how it should be retried.

YOU DO NOT NEED TO TOUCH THESE METHODS TO CREATE HELIOS SERVICES. These methods manage interaction between Helios and TheSchwartz. You only need to be concerned with these methods if you are attempting to extend core Helios functionality.

max_retries()

Controls how many times a job will be retried.

retry_delay()

Controls how long (in secs) before a failed job will be retried.

These two methods should return the number of times a job can be retried if it fails and the minimum interval between those retries, respectively. If you don't define them in your subclass, they default to zero, and your job(s) will not be retried if they fail.

work()

The work() method is the method called by the underlying TheSchwartz::Worker (which in turn is called by the helios.pl service daemon) to perform the work of a job. Effectively, work() sets up the worker process for the Helios job, and then calls the service subclass's run() method to run it.

The work() method is passed a job object from the underlying TheSchwartz job queue system. The service class is instantiated, and the the job is recast into a Helios::Job object. The service's configuration parameters are read from the system and made available as a hashref via the getConfig() method. The job's arguments are parsed from XML into a Perl hashref, and made available via the job object's getArgs() method. Then the service object's run() method is called, and is passed the Helios::Job object.

Once the run() method has completed the job and returned, work() determines whether the worker process should exit or stay running. If OVERDRIVE mode is enabled and the service hasn't been HALTed or told to HOLD, the worker process will stay running, and work() will be called to setup and run another job. If the service is not in OVERDRIVE mode, the worker process will exit.

Portions of this method, where noted, are Copyright (C) 2011-2012 by Andrew Johnson. See the COPYRIGHT AND LICENSE section elsewhere in this document for specific terms.

metarun($job)

Given a metajob, the metarun() method runs the job, returning 0 if the metajob was successful and nonzero otherwise.

This is the default metarun() for Helios. In the default Helios system, metajobs consist of multiple simple jobs. These jobs are defined in the metajob's argument XML at job submission time. The metarun() method will burst the metajob apart into its constituent jobs, which are then run by another service.

Metajobs' primary use in the base Helios system is to speed the job submission process of large job batches. One metajob containing a batch of thousands of jobs can be submitted and burst apart by the system much faster than thousands of individual jobs can be submitted. In addition, the faster jobs enter the job queue, the faster Helios workers can be launched to handle them. If you have thousands (or tens of thousands, or more) of jobs to run, especially if you are running your service in OVERDRIVE mode, you should use metajobs to greatly increase system throughput.

COPYRIGHT

This method is Copyright (C) 2011-2012 by Andrew Johnson.

See the COPYRIGHT AND LICENSE section elsewhere in this document for specific copyright and license terms.

ACCESSOR METHODS

These accessors will be needed by subclasses of Helios::Service.

get/setConfig()
get/setHostname()
get/setIniFile()
get/setJob()
get/setJobType()
errstr()
debug()

Most of these are handled behind the scenes simply by calling the prep() method.

After calling prep(), calling getConfig() will return a hashref of all the configuration parameters relevant to this service class on this host.

If debug mode is enabled (the HELIOS_DEBUG env var is set to 1), debug() will return a true value, otherwise, it will be false. Some of the Helios::Service methods will honor this value and log extra debugging messages either to the console or the Helios log (helios_log_tb table). You can also use it within your own service classes to enable/disable debugging messages or behaviors.

CONSTRUCTOR

new()

The new() method doesn't really do much except create an object of the appropriate class. (It can overridden, of course.)

It does set the job type for the object (available via the getJobType() method).

INTERNAL SERVICE CLASS METHODS

When writing normal Helios services, the methods listed in this section will have already been dealt with before your run() method is called. If you are extending Helios itself or instantiating a Helios service outside of Helios (for example, to retrieve a service's config params), you may be interested in some of these, primarily the prep() method.

prep()

The prep() method is designed to call all the various setup routines needed to get the service ready to do useful work. It:

  • Pulls in the contents of the HELIOS_DEBUG and HELIOS_INI env vars, and sets the appropriate instance variables if necessary.

  • Calls the getConfigFromIni() method to read the appropriate configuration parameters from the INI file.

  • Calls the getConfigFromDb() method to read the appropriate configuration parameters from the Helios database.

Normally it returns a true value if successful, but if one of the getConfigFrom*() methods throws an exception, that exception will be raised to your calling routine.

getConfigFromIni([$inifile])

The getConfigFromIni() method opens the helios.ini file, grabs global params and config params relevant to the current service class, and returns them in a hash to the calling routine. It also sets the class's internal {config} hashref, so the config parameters are available via the getConfig() method.

Typically service classes will call this once near the start of processing to pick up any relevant parameters from the helios.ini file. However, calling the prep() method takes care of this for you, and is the preferred method.

getConfigFromDb()

The getConfigFromDb() method connects to the Helios database, retrieves config params relevant to the current service class, and returns them in a hash to the calling routine. It also sets the class's internal {config} hashref, so the config parameters are available via the getConfig() method.

Typically service classes will call this once near the start of processing to pick up any relevant parameters from the helios.ini file. However, calling the prep() method takes care of this for you.

There's an important subtle difference between getConfigFromIni() and getConfigFromDb(): getConfigFromIni() erases any previously set parameters from the class's internal {config} hash, while getConfigFromDb() merely updates it. This is due to the way helios.pl uses the methods: the INI file is only read once, while the database is repeatedly checked for configuration updates. For individual service classes, the best thing to do is just call the prep() method; it will take care of things for the most part.

getFuncidFromDb()

jobsWaiting()

Scans the job queue for jobs that are ready to run. Returns the number of jobs waiting. Only meant for use with the helios.pl service daemon.

getDriver()

Returns a Data::ObjectDriver object for use with the Helios database.

shouldExitOverdrive()

Determine whether or not to exit if OVERDRIVE mode is enabled. The config params will be checked for HOLD, HALT, or OVERDRIVE values. If HALT is defined or HOLD == 1 this method will return a true value, indicating the worker process should exit().

This method is used by helios.pl and Helios::Service->work(). Normal Helios services do not need to use this method directly.

METHODS AVAILABLE TO SERVICE SUBCLASSES

The methods in this section are available for use by Helios services. They allow your service to interact with the Helios environment.

dbConnect($dsn, $user, $password)

Method to connect to a database. If parameters not specified, uses dsn, user, password from %params hash (the Helios database).

This method uses the DBI->connect_cached() method to attempt to reduce the number of open connections to a particular database.

logMsg([$job,] [$priority_level,] $message)

Given a message to log, an optional priority level, and an optional Helios::Job object, logMsg() will record the message in the logging systems that have been configured. The internal Helios logging system is the only system enabled by default.

In addition to the log message, there are two optional parameters:

$job

The current Helios::Job object being processed. If specified, the jobid will be logged in the database along with the message.

$priority

The priority level of the message as defined by Helios::LogEntry::Levels. These are really integers, but if you import Helios::LogEntry::Levels (with the :all tag) into your namespace, your logMsg() calls will be much more readable. There are 8 log priority levels, corresponding (for historical reasons) to the log priorities defined by Sys::Syslog:

 name         priority
 LOG_EMERG    0
 LOG_ALERT    1
 LOG_CRIT     2
 LOG_ERR      3
 LOG_WARNING  4
 LOG_NOTICE   5
 LOG_INFO     6
 LOG_DEBUG    7

LOG_DEBUG, LOG_INFO, LOG_NOTICE, LOG_WARNING, and LOG_ERR are the most common used by Helios; LOG_INFO is the default.

The host, process id, and service class are automatically recorded with your log message. If you supplied either a Helios::Job object or a priority level, these will also be recorded with your log message.

This method returns a true value if successful and throws an exception if errors occur.

LOGGING SYSTEM CONFIGURATION

Several parameters are available to configure Helios logging. Though these options can be set either in helios.ini or in the Ctrl Panel, it is strongly recommended these options only be set in helios.ini. Changing logging configurations on-the-fly could potentially cause a Helios service (and possibly your whole collective) to become unstable!

The following options can be set in either a [global] section or in an application section of your helios.ini file.

loggers

loggers=HeliosX::Logger::Syslog,HeliosX::Logger::Log4perl

A comma delimited list of interface classes to external logging systems. Each of these classes should implement (or otherwise extend) the Helios::Logger class. Each class will most likely have its own configuration parameters to set; consult the documentation for the interface class you're trying to configure.

internal_logger

internal_logger=on|off

Whether to enable the internal Helios logging system as well as the loggers specified with the 'loggers=' line above. The default is on. If set to off, the only logging your service will do will be to the external logging systems.

log_priority_threshold

log_priority_threshold=1|2|3|4|5|6

You can specify a logging threshold to better control the logging of your service on-the-fly. Unlike the above parameters, log_priority_threshold can be safely specified in your Helios Ctrl Panel. Specifying a 'log_priority_threshold' config parameter in your helios.ini or Ctrl Panel will cause log messages of a lower priority (higher numeric value) to be discarded. For example, a line in your helios.ini like:

log_priority_threshold=6

will cause any log messages of priority 7 (LOG_DEBUG) to be discarded.

The logMsg() method is Copyright (C) 2009 by Andrew Johnson

This method is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.0 or, at your option, any later version of Perl 5 you may have available.

WARRANTY

This software comes with no warranty of any kind.

getJobArgs($job)

Given a Helios::Job object, getJobArgs() returns a hashref representing the parsed job argument XML. It actually calls the Helios::Job object's parseArgs() method and returns its value.

JOB COMPLETION METHODS

These methods should be called in your Helios service class's run() method to mark a job as successfully completed, failed, or failed permanently. They actually call the appropriate methods of the given Helios::Job object.

completedJob($job)

Marks $job as completed successfully.

failedJob($job [, $error][, $exitstatus])

Marks $job as failed. Allows job to be retried if your subclass supports that (see max_retries()).

failedJobPermanent($job [, $error][, $exitstatus])

Marks $job as permanently failed (no more retries allowed).

burstJob($metajob)

Given a metajob, burstJob bursts it into its constituent jobs for other Helios workers to process. Normally Helios::Service's internal methods will take care of bursting jobs, but the method can be overridden if a job service needs special bursting capabilities.

SERVICE CLASS DEFINITION

These are the basic methods that define your Helios service. The run() method is the only one required.

run($job)

This is a default run method for class completeness. You have to override it in your own Helios service class.

MaxRetries() and RetryInterval()

These methods control how many times a job should be retried if it fails and how long the system should wait before a retry is attempted. If you don't defined these, jobs will not be retried if they fail.

JobClass()

Defines which job class to instantiate the job as. The default is Helios::Job, which should be fine for most purposes. If necessary, however, you can create a subclass of Helios::Job and set your JobClass() method to return that subclass's name. The service's work() method will instantiate the job as an instance of the class you specified rather than the base Helios::Job.

NOTE: Please remember that "jobs" in Helios are most often only used to convey arguments to services, and usually only contain enough logic to properly parse those arguments and mark jobs as completed. It should be rare to need to extend the Helios::Job object. OTOH, if you are attempting to extend Helios itself to provide new abilities and not just writing a normal Helios application, you can use JobClass() to use your extended job class rather than the default.

SEE ALSO

helios.pl, Helios::Job, Helios::Error, Helios::ConfigParam, Helios::LogEntry, TheSchwartz, XML::Simple, Config::IniFiles, Sys::Syslog

AUTHOR

Andrew Johnson, <lajandy at cpan dot org>

COPYRIGHT AND LICENSE

Copyright (C) 2008-9 by CEB Toolbox, Inc., except as noted.

Portions of this software, where noted, are Copyright (C) 2009 by Andrew Johnson.

Portions of this software, where noted, are Copyright (C) 2011-2012 by Andrew Johnson.

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.0 or, at your option, any later version of Perl 5 you may have available.

WARRANTY

This software comes with no warranty of any kind.