Changes for version 2.40_1731 - 2012-04-25
- -Corrected recent version history in the Changes file. Sorry for the mixups. -Helios::Service and Helios::Job: added deferredJob() and deferred() methods to defer processing of a job even though it was available in the job queue. These methods (for now) simply expose the declined() feature added in TheSchwartz 1.10; no Helios job history is recorded for a deferred job.
Changes for version 2.40_1361 - 2012-04-01
- -helios.pl: now calls the service class prep() method on startup rather than getConfigFromIni() and getConfigFromDb() separately. This ensures proper setup of the loggers and Data::ObjectDriver db connection (see below). -helios.pl: changed startup message so perl doesn't carp a warning if the service class doesn't have a $VERSION defined. -Helios::Job, Helios::Logger, Helios::Service: changes to manage the creation of Data::ObjectDriver connections to the collective database. In previous Helios versions, getDriver() methods in Helios::Job and Helios::Service would always create new D::OD objects. This can potentially lead to many open but inactive connections to the database as new objects are needlessly created to utilize connections Helios already has access to (this problem has been observed using Helios with Oracle databases). The getDriver() methods of Helios::Job and Helios::Service now attempts to retrieve a cached copy of the D::OD object and calls the new initDriver() method if a driver doesn't already exist. This way only one driver object will be created to service all database activity between Helios::Service and Helios::Job. This same functionality was added to Helios::Logger so all logger classes now have easy access to the Helios collective database through the cached object. -Helios::Service and Helios::Logger: changes were made to the logger initialization process. Logger classes are now initialized when Helios::Service->prep() method is called, not when the first call to logMsg() happens. In addition, before a logger's init() method is called, the setDriver() method is called with an already initialized Data::ObjectDriver object so the logger will not need to create its own. This is more efficient and prevents the problem mentioned above with D::OD driver creation. Loggers written for Helios 2.40 will continue to work fine with 2.41, but loggers needing access to the collective database can use the new set/get/initDriver() methods to increase database efficiency. See the Helios::Logger documentation for more information on the new methods. -Helios::Logger::Internal: updated to conform to the changes above. The getDriver() method was removed (Helios::Logger->getDriver() supercedes it) and the init() method now calls getDriver() to make sure a D::OD has been created.
Changes for version 2.40_1321 - 2012-03-27
- -helios.pl: added registration_interval as a configuration parameter (previously it was hard-coded to 300 seconds in helios.pl). The "registration_interval" parameter is the amount of time (in secs) between service daemon "collective check-ins" (when a service daemon records its current status in the HELIOS_WORKER_REGISTRY_TB table. This table is used to create the Helios::Panoptes Collective Admin page, and is also useful for system monitoring and statistics. -helios.pl: set new defaults for zero_sleep_interval (10) and registration_interval (60). These new defaults should make Helios more responsive in low load situations and generally work better for more users out-of-the-box. (The old defaults geared Helios more for large volumes of long-running jobs on heavily loaded databases. The new defaults should work for a better range of small- to mid-sized loads.) If these new defaults create too much traffic for your database, you can set new larger values in your helios.ini file to decrease database traffic.
Changes for version 2.40_1271 - 2012-03-25
- -helios.pl: changes to prevent a worker from transmuting to a new service daemon (caused by database instability during transition between helios.pl, TheSchwartz->work(), and Helios::Service->work()
- submitJob.pl - CGI script to receive jobs for Helios via HTTP POST
- helios.pl - Launch a daemon to service jobs in the Helios job processing system
- helios_job_submit.pl - Submit a job to the Helios job processing system from the cmd line
- helios_log_clean.pl - Clean old log and history entries from the Helios database
- Helios::Tutorial - a tutorial for getting started with Helios
- Bundle::Helios::Generic - install all Helios related modules
- Bundle::Helios::RedHat - install all Helios related modules on Red Hat-based systems
- Helios - a distributed job processing system
- Helios::Error - a convenience class to import all Helios::Error exception classes
- Helios::Error::BaseError - base exception class for Helios services
- Helios::Error::DatabaseError - exception class for Helios indicating a database error occurred
- Helios::Error::Fatal - fatal exception class for Helios indicating a job failed but can be re-attempted
- Helios::Error::FatalNoRetry - fatal exception class for Helios indicating a job failed and the error was so serious the job should not be reattempted.
- Helios::Error::InvalidArg - exception class for Helios indicating a job's args are invalid
- Helios::Error::LoggingError - exception class for Helios indicating an error occurred in the logging subsystem
- Helios::Error::Warning - exception class for Helios indicating a job was successful but it encountered errors during processing
- Helios::Job - base class for jobs in the Helios job processing system
- Helios::Logger - Base class for sending Helios logging information to external loggers
- Helios::Logger::Internal - Helios::Logger subclass implementing Helios internal logging
- Helios::MetajobBurstService - base class for metajob burst services in Helios
- Helios::Service - base class for services in the Helios job processing system
- Helios::TestService - Helios::Service subclass useful for testing