0.5 Release Notes

gCore 0.5.0RC introduces the following changes:

• gHN

• a more streamlined distribution, with minimal runtime dependencies to legacy services for a faster gHN startup.

The number of Globus services that run in a gHN has been limited to those required to support publication and notification functionality. In particular, the historical dependency on Globus Registry Service has been finally eliminated and its output in nohup.out replaced with a native version that separates the display of gCube services from the display of (the surviving) Globus services. In addition, a large number of legacy configuration, dependencies, and test elements have been removed from the distribution. It is anticipated that this streamlining process will continue in future releases.

• the integration of the ResultSet as a Local Service for simplified configuration, faster dynamic deployment, and query-by-reference support in gCore.

The ResultSet service and associated libraries are now distributed along with gCore in reflection of their widespread use within the infrastructure. This simplifies the definition and maintenance of the majority of service profiles (no need of explicit dependencies), streamlines dynamic deployment processes (less overhead), and makes it possible to support query-by-reference in gCore.

• a more accurate and gCube-compliant model of gHN lifecycle.

The gHN lifecycle now separates ‘ready-ness’ (the completed activation of deployed RIs) from ‘certification’ (all deployed RIs are operational in the infrastructure), both at startup and during later phases. It also separates failure from shutdown, and in both cases notifies the components of activated RIs before triggering a countdown to the end of the JVM process. The handling of all the phases of the gHN lifetime has significantly improved, with clear log feedback and timely publication in the infrastructure. As to the latter, gHN profiles now include an explicit field that marks their status.

• more modular and informative logging for improved debugging and monitoring.

Local Services have now separate file appenders, and so does Globus. Logger propagation procedures have been improved to support separate file appenders for individual services (highly recommended during development). Log entries now report cumulative timings on a per-thread basis, and service calls are fully timed both in case of success and in case of failure. All logfiles are now gathered in a dedicated directory under the gCore installation.

• new gHN management interface for local development and monitoring.

The gHN now offer a JMX interface for local monitoring and management of gHN, RIs, and loggers (typically via jconsole). Loggers levels, RI and gHN status, RI current scopes, RI call statistics, can all be inspected and/or acted upon for testing purposes. It is anticipated that further information will be exposes through the interface in future release.

• automatic probing of free ports within configurable range for generalised approach to port binding.

The gHN configuration can now specify a range of ports and the gHN context can be asked to probe for the first free port in the range. The facility is currently used by the new management interface (see above), but it is generically available to all gHN clients.

• simplified offline use of the gHN through dedicated configuration file.

The gHN context now uses a separate gHN configuration for offline use (in GHNConfig.client.xml), which can diverge arbitrarily from the configuration used in online mode (in GHNConfig.xml). This is particularly intended to simplify the execution of clients that operate in scopes that differ from those in which the gHN did, does, or will operate.

• new Service Maps (and in-Profile gCore versioning?).

[please summarise and motivate]

• Services

• full parallelisation of service activation for a faster gHN startup.

The activation of services within a starting gHN is now entirely asynchronous. The gHN activation thread merely ‘touches’ port-types and homes of deployed services and proceeds quickly to completion. After the service components have been awaken, they synchronise via the the exchange of events mediated by the service context. In a similar mannaer, the service context synchronises with the gHN context to report progress and failures. The service lifecycle now separates operational failures from gHN-induced shutdowns.. Callbacks for all lifecycle events are now available for port-type and home components, not only for service contexts. The handling of all the phases of the RI lifetime has significantly improved, with clear log feedback and timely publication in the infrastructure.