View on
MetaCPAN is shutting down
For details read Perl NOC. After June 25th this page will redirect to
Andrew Johnson > Helios-2.61 > Helios::Config



Annotate this POD



Open  0
View/Report Bugs
Module Version: 2.60   Source   Latest Release: Helios-2.83


Helios::Config - base class for Helios configuration system


 # to determine a service's config based on
 # a particular conf file and host
 use Helios::Config;
     CONF_FILE => '/path/to/helios.ini',
     HOSTNAME  => 'host',
     SERVICE   => 'ServiceName'
 my $config = Helios::Config->parseConfig();
 # if $HELIOS_INI env var is set and current host is used
 use Helios::Config;
 Helios::Config->init(SERVICE => 'ServiceName');
 my $config = Helios::Config->parseConfig();
 # same as above; parseConfig() will automatically call init()
 use Helios::Config;
 my $config = Helios::Config->parseConfig(SERVICE => 'ServiceName');
 # you can also use accessor methods; for example, with Helios::TestService:
 use Helios::Config;
 my $config = Helios::Config->parseConfig();

 # catch config errors with eval {}
 # Try::Tiny works too 
 use Helios::Config;
 my $config;
 eval {
        Helios::Config->init(SERVICE => 'Helios::TestService');
        $config = Helios::Config->parseConfig();
 } or do {
        my $E = $@;
        if ( $E->isa('Helios::Error::ConfigError') ) {
                print "Helios configuration error: $E\n";
        } else {
                print "I do not know what happened, but it was bad.\n";


Helios::Config is the standard class for determining configuration information in the Helios framework. It handles parsing configuration information from the Helios configuration file, and determining the configuration for services from information in the Helios collective database. Helios::Config also acts as a base class for the Helios configuration API; services can define specialized Helios::Config subclasses to extend configuration subsystem functionality.

Normally, the developer of Helios services does not need to interact with Helios::Config directly. Helios normally handles all configuration transparently during service setup before a service's run() method is called. A Helios service need only call its getConfig() method to retrieve a hashref of its configuration parameters. Only those wanting to retrieve a Helios service configuration outside of the service (e.g. to write an external utility as an adjunct to a Helios service) or those with advanced configuration needs will need to work with Helios::Config directly.

It should be noted that, like Helios::Logger subclasses, Helios::Config methods are actually class methods, not instance (object) methods. If you need to implement other methods outside of the methods defined below, make sure you implement them as class methods.


Helios::Config provides 7 set/get accessor pairs to provide access to configuration data. There are 3 categories of accessors: ones that need to be set before configuration parsing is initialized, those that are used during configuration parsing, and those that hold the end results of the parsing procedure (i.e. the actual configuration and the Helios service will need).


These need to be set before configuration parsing is initialized with the init() method. If they are not set, the init() method will try to set them from data in the environment.

 set/getConfFile()        path to the Helios conf file 
                          -defaults to $HELIOS_INI env variable
 set/getHostname()        hostname the Helios service is running on
                          -defaults to results of Sys::Hostname::hostname()
 set/getServiceName()     name of the running Helios service
                          -defaults to undefined, which will cause the
                           resulting config to contain the contents of the 
                           helios.ini [global] section only


These methods will be set during the configuration parsing process. Most Helios service developers will not need to be aware of these, but if you are developing a specialized Helios::Config subclass, they may be useful.

 set/getConfFileConfig()  the config info parsed from helios.ini
 set/getDbConfig()        the config info parsed from the collective database
 set/getDriver()          Data::ObjectDriver object connected to collective db


This method contains the results of the configuration parsing process. In other words, the actual configuration information for the given Helios service.

 set/getConfig()          the complete config info from both conf file & db



Prepares Helios::Config to parse the configuration for a particular Helios service. Accepts initialization information as a hash of parameters; if a parameter is not given, init() will attempt to default to values based on information from the environment.

The init() method accepts 4 arguments:

 CONF_FILE  path to the helios.ini file (default: $HELIOS_INI env var)
 HOSTNAME   hostname (default: current hostname from Sys::Hostname::hostname())
 DEBUG      enable/disable debug mode (default: disabled)
 SERVICE    name of the Helios service to determine configuration for 
            (default: none)

For example, to initialize Helios::Config to parse the configuration information from /etc/helios/helios.ini for the Helios::TestService service on the host named, one would call init() as:

        CONF_FILE => '/etc/helios/helios.ini',
        HOSTNAME  => '',
        SERVICE   => 'Helios::TestService'

Normally the host and config file are specified by the operating system and the $HELIOS_INI environment variable, so a more typical init() call in a properly set up Helios collective would only specify the service:

 Helios::Config->init(SERVICE => 'Helios::TestService');



Given a set of optional initialization parameters, parseConfig() will parse the helios.ini config file and query the Helios collective database for configuration information for a particular Helios service, combining the information into a single set of configuration information, which is returned to the calling routine as a hash reference.

The parseConfig() method controls the actual parsing and derivation of a service's configuration. This process has 4 steps:

parseConfFile([$conf_file, $service_name])

Given an optional conf file and an optional service name, parseConfFile() parses the conf file and returns the resulting hashref to the calling routine. It also makes the hashref available via the getConfFileConfig() accessor. If either the conf file or the service is not specified, the values from the getConfFile() and/or getServiceName accessor(s) are used. The conf file location is set by init() to the value of the $HELIOS_INI environment variable unless otherwise specified.

The default Helios configuration file is the common .ini file format, where section headings are denoted by brackets ([]). Lines not starting with [ are considered parameters belonging to the last declared section. Lines starting with # or ; are considered comments and are ignored. See Config::IniFiles (the default underlying file parser) for more format details.

Helios requires at least one section, [global], in the conf file, which should contain at least 3 parameters:

 dsn       DBI datasource name of the Helios collective database
 user      the user to use to access the Helios collective db
 password  the password to use to access the Helios collective db

Without these, the daemon will be unable to connect to the collective database and will fail to start.

You may also specify other configuration parameters in the [global] section. Options set in the [global] section will appear in the configuration parameters of all services using that conf file. This can be useful if you need multiple services on a host to share a configuration (e.g. you want to configure all services on a host to log messages to a syslogd facility using HeliosX::Logger::Syslog).

In addition to [global], you can create other sections as well. If a section name matches the service name specified, the configuration parameters in that section will be included in the config hash returned to the calling routine. You can use this feature to set defaults for a service, or to set sensitive parameters (e.g. passwords) that you do not want to be changable from the Helios::Panoptes web admin console.

For example, a Helios conf file that configures the Helios collective db and sets some config parameters for the Helios::TestService service would look something like:


parseConfDb([$service_name, $hostname])

The parseConfDb() method queries the Helios collective database for configuration parameters matching the specified service name and hostname and returns a hashref with those parameters to the calling routine. If the service name and hostname are not specified, the values returned from the getServiceName() and getHostname() accessors are used. The getHostname() value is normally set by init() to the value returned by Sys::Hostname::hostname() unless otherwise specified.

The default parseConfDb() queries the HELIOS_PARAMS_TB table in the Helios collective database. Two separate queries are done:

The results of these two queries are merged, and the resulting hashref returned to the calling routine. Config parameters for a specific host override config params for all ('*') hosts.

Configuration parameters in the Helios collective database can be set using the Helios::Panoptes web admin console or using your database's standard SQL commands.


Helios service developers with more advanced configuration needs than Helios::Config supplies can extend the Helios::Config class to override its methods and/or provide methods of their own. There are 2 steps required to take advantage of this functionality:


The Helios system defines a large number of configuration parameters. Some of these affect the operation of the daemon, others worker processes, and some can affect both. Aside from these reserved parameter names, the configuration parameters your Helios service uses are largely up to you.

Helios configuration parameters that affect worker process launching and management are usually in ALL CAPS. This helps set them apart from other application-level parameters.

Collective database configuration parameters

These are the most important parameters in helios.ini. They must be declared in the [global] section. Without them, will be unable to connect to the collective database and will fail to start.



The dsn parameter is the DBI datasource name of the Helios collective database.



The user parameter is the user to use when connecting to the Helios collective database.



The password parameter is the password to use when connecting to the Helios collective database.


 options=private_option=>'string',private_option2=>'another string'

The options parameter is used when special DBI options are needed when connecting to the Helios collective database. Normally, this parameter should not be necessary but is made available for users who may need to specify special parameters in their database connections anyway.

Other parameters



Sets the path where daemon will write its PID files. This should be an absolute path to a directory writable by the Helios user (the user the daemon will run as). Each service daemon will write a PID file incorporating the name of the service class it has loaded into this directory.

If this directory does not exist or is not writable by the Helios user, the daemon will fail to start.

DEFAULT: /var/run/helios


The number of seconds to wait before a service daemon "checks in" to the collective database. Periodically will update a table in the Helios collective database for monitoring purposes. This allows the Helios::Panoptes admin console to provide the Collective Admin view, and enables Panoptes and other utilities to see if a service daemon has crashed or has encountered some other type of error. The default 60 seconds should be fine for most purposes, but can be increased to reduce database load if necessary.


Service-specific Tuning Parameters for

There are several parameters useful for tuning the service daemon to work better with your Helios service. Helios and the daemon default to behavior that should work well for processing jobs that last a short amount of time (generally 30 seconds or less). If your jobs consistently last longer than a minute, or can potentially put a strain on resources like a database or a file server, you may wish to adjust the following parameters.

These parameters are not dynamic and should be set in the Helios conf file, either in the [global] section or a section matching your service's name.



The master_launch_interval is the amount of time in seconds waits after launching workers before it attempts to launch workers again. Normally the default of 1 second is fine, but if you need to slow how quickly new worker processes are started, you can increase this number.




The zero_launch_interval is the amount of time in seconds waits to launch workers again after the MAX_WORKERS limit has been reached. Once launches the MAX_WORKERS number of workers, it will not launch more even if there are available jobs in the queue. If a particular service's jobs usually take longer than the default of 10 seconds, or you are using OVERDRIVE mode so your worker processes persist until no more jobs available, increasing zero_launch_interval may decrease needless database queries. For most cases, the default of 10 seconds should be adequate.




The zero_sleep_interval is the amount of time between checks for available jobs in the job queue when the job queue is empty. If the daemon determines there are no available jobs for a service, it sleeps zero_sleep_interval seconds and then checks again. If there are available jobs, it starts to launch workers; if there are still none, it sleeps another zero_sleep_interval seconds and checks again. This can cause jobs to "sit" in the queue for some seconds before workers are launched to service them. If you do not have enough jobs consistently entering the job queue to keep workers running in OVERDRIVE mode, decreasing this number will make more responsive by launching workers for your jobs sooner (at the expense of extra repeated queries of the job queue in the database). If your jobs can wait in the job queue for awhile and you do not have many entering the system, increasing this number can reduce the number of needless queries to your database.


Worker process management

The following configuration parameters affect the management of workers and how they run services and process jobs. These are most typically set in the collective database configuration table for each service, thus they are ALL CAPS to separate them from your services' own configuration parameters. Unlike the parameters in the previous section, these configuration parameters are dynamic and can be changed via Helios::Panoptes or SQL commands to your collective database.



Puts a Helios service in Hold Mode. All worker processes shut down after finishing the current job, and the service daemon ignores avaliable jobs in the job queue. Set HOLD to 0 or delete it from the configuration to cause Helios to return to Normal Mode.




Causes a service daemon and all its workers to shutdown. When HALT is set for a service, worker processes exit after the current job is finished. The service daemon waits MAX_WORKER_TTL_WAIT_INTERVAL seconds for workers to finish, and sends any remaining workers a SIGKILL signal to eliminate any stragglers. The daemon then removes its registration entry from the collective database and exits.

Warning: BE CAREFUL about setting a HALT for a service for all hosts (hostname='*'). This will shutdown all instances of that Helios service in the ENTIRE collective, and the only way to restart them is to log into the host and start them manually. If you need to perform maintenance on hosts in a production Helios collective, you most likely want to HOLD all instances of a service and then HALT each instance individually as needed.

DEFAULT: none (the presence of HALT in the config causes a shutdown regardless of its value)



Along with OVERDRIVE, MAX_WORKERS is the most powerful configuration parameter in the Helios framework. Setting MAX_WORKERS allows a service daemon to launch multiple workers at a time to service jobs, up to the MAX_WORKERS limit.

Normally, when the service daemon sees available jobs in the job queue, it starts to launch worker processes to service the jobs. Normally, it launches workers gradually, one at a time, in order to prevent overtaxing resources (and to allow the launched workers time to do actually run the jobs). If there are the same or more jobs in the queue as the MAX_WORKERS value, will "blitz" (launch the maximum amount of workers) to attempt to run the jobs in the queue as quickly as possible. This "blitzing" feature is controlled by the WORKER_BLITZ_FACTOR parameter, so if you want want Helios to blitz workers before there are that many jobs available in the queue, adjust WORKER_BLITZ_FACTOR downward to allow to launch more worker processes faster.




Setting OVERDRIVE causes a worker process to persist in memory continuing to run jobs from the job queue until all available jobs for the loaded service are exhausted. Coupled with MAX_WORKERS, allows you to maximize job throughput by eliminating repeated process startup procedures and enabling caching of database connections and other data structures.

Unless your service is designed to run long-running jobs lazily, you almost certainly want to set OVERDRIVE to 1. It is set to 0 by default because indiscriminately running untested, potentially unsafe services can cause unexpected, even disasterous behavior. Make sure your service runs in Normal Mode first, then test it in Overdrive Mode throughly before you deploy it.




Use WORKER_BLITZ_FACTOR to set the service daemon to launch more worker processes sooner. Normally, launches one worker process at a time unless there are as many jobs as the MAX_WORKERS limit; if there are that many jobs in the queue, Helios "blitzes" (launches MAX_WORKERS number of workers). If you want Helios to blitz workers sooner, adjust WORKER_BLITZ_FACTOR lower.

The WORKER_BLITZ_FACTOR is a decimal between 0 and 1. If your service's MAX_WORKERS parameter is set to 50 but you want Helios to launch the maximum number of workers anytime there are at least 25 available jobs in the job queue, you should set WORKER_BLITZ_FACTOR to 0.5.

DEFAULT: 1 (workers do not blitz until there are at least MAX_WORKERS jobs available in the job queue)



Use LAZY_CONFIG_UPDATE to increase worker process performance by reducing the number of configuration parameter refreshes a worker process performs in Overdrive Mode. In Overdrive Mode, a worker process refreshes the service configuration from the collective database just before it calls the service's run() method. With LAZY_CONFIG_UPDATE set to 1, this configuration refresh is performed only before every 10th job the worker process runs, reducing database queries and thus increasing performance.

NOTE: The configuration refresh is where worker processes pick up HOLD and HALT parameters, so using LAZY_CONFIG_UPDATE will cause worker processes to be less responsive when holding jobs or halting the service. If your service's configuration does not change often, you can activate LAZY_CONFIG_UPDATE and see if your service experiences a noticable increase.




The maximum amount of time in seconds to allow a worker process for a service to run. If a worker process continues to run past this threshold, the service daemon will assume it has become stuck in some way and will send it a SIGKILL signal (9) to kill it (real world situations have shown softer signals are unreliable in such situations). If you set this and find worker processes not experiencing problems are being unnecessarily killed, you may need to increase the WORKER_MAX_TTL_WAIT_INTERVAL (below).

DEFAULT: none; workers running in Normal Mode run until their job is complete; workers in Overdrive Mode work until no more jobs are available in the job queue.


Number of seconds a service daemon will wait for a worker that has reached its WORKER_MAX_TTL to exit. If a worker process continues running past WORKER_MAX_TTL + WORKER_MAX_TTL_WAIT_INTERVAL seconds, will assume the worker process has hung in some way and will send it a SIGKILL (9) signal to kill it.




This to support certain legacy behaviors for Helios services developed before Helios 2.40. You almost certainly do not need to set this.

DEFAULT: 0 (ignore the return value of the service's run() method)




Specify a comma-separated list of external logging classes to use to log information. Each of the modules listed should implement the Helios::Logger interface class.

Each logger class likely will have its own configuration parameters; see the logger's documentation for the appropriate configuration information.

The Helios internal logger (Helios::Logger::Internal) is automatically added to this list, unless internal_logger (below) is turned off.




Whether the Helios internal logger (Helios::Logger::Internal) should be used to log information. The internal logger logs information to a table in the Helios collective database, and is the log system used by the Helios::Panoptes System Log view. If you want to only use an external logging system such as HeliosX::Logger::Log4perl, you can turn off Helios logging completely by setting internal_logger to 0 or 'off'.




The log level above which the internal logger discards log messages. Specifying a log_priority_threshold will cause log messages of a lower priority (higher numeric value) to be discarded. For example, a log_priority_threshold of 6 (LOG_INFO) will cause log messages with a priority of 7 (LOG_DEBUG) to be discarded.

See the Helios::Logger::Internal documentation for more information on log thresholds.

DEFAULT: undefined (all log messages are logged)


Andrew Johnson, <lajandy at cpan dot org>


Copyright (C) 2012 by Logical Helion, LLC.

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.


This software comes with no warranty of any kind.

syntax highlighting: