Helios-2.40_2071

Changes for version 2.40_2071 - 2012-05-20

Helios 2.41 RC1 -Removed debug messages -Minor update to tests

Changes for version 2.40_1931 - 2012-05-09

-Removed Bundle::Helios::RedHat. Ultimately, it didn't work any better (or worse) than using 'install Helios' command with the CPAN shell. Bundle::Helios::Generic seems to work well, however. -First official Oracle schema added. This schema is based on a schema created by the Oracle MySQL to Oracle schema conversion tool. It will probably need some tweaking to fit in with your organization's Oracle setup (grants, tablespaces, etc). -Changed getDriver() in Helios::Service and Helios::Logger to disable caching of the Data::ObjectDriver object. There were issues if the database connection experienced problems. This feature will probably reappear in a future release (after more testing).

Changes for version 2.40_1732 - 2012-04-25

-Corrected Helios::Job->deferred(). It works and agrees with the documentation now.

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()