Difference between revisions of "Migration Guidelines from 0.4.4 to 0.5"
From GCube System
(New page: gCore <code>0.5.0RC</code> requires or supports the following changes to code compliant with the 0.4.4 release: ==== Changes Related to the gHN ==== ==== Changes Related to Services ===...) |
|||
Line 1: | Line 1: | ||
− | |||
gCore <code>0.5.0RC</code> requires or supports the following changes to code compliant with the 0.4.4 release: | gCore <code>0.5.0RC</code> requires or supports the following changes to code compliant with the 0.4.4 release: | ||
==== Changes Related to the gHN ==== | ==== Changes Related to the gHN ==== | ||
+ | |||
+ | :* ''package change in <code>ResultSet</code> components'' | ||
+ | ::The inclusion of the <code>ResultSet</code> service and related components in gCore has coincided with a refactorisation of their package structure. In particular, fully qualified names that begun with <code>org.gcube.searchservice</code> begin now with <code>org.gcube.common.searchservice</code>. | ||
+ | |||
+ | :* ''new log files and log file location.'' | ||
+ | :: All gCore logs are now located in <code>$GLOBUS_LOCATION/logs</code>, while <code>nohup.out</code> remains in <code>$GLOBUS_LOCATION</code> (now regardless of where the <code>$GLOBUS_LOCATION/bin/gcore-start-container</code> is run from). The gHN's logs remains the same (<code>container.fulllog</code>, <code>container.log</code>), but the local services have dedicated log files (<code>ghnmanager.log</code>,<code>deployer.log</code>, <code>delegation.log</code>, <code>rs.log</code>). Globus logs are now collected in a separate log file <code>globus.log</code> and do not propagate to the contatainer's log files (default log level for globus is <code>WARN</code>). Developers are recommended to configure service-specific logs during development. For this purpose, the configuration for local services in <code>$GLOBUS_LOCATION/container-log4j.properties</code> can be used as templates. | ||
+ | |||
+ | :* ''new lower bound on memory requirement for gHNs.'' | ||
+ | :: The gHN now requires the allocation of '''1GB''' of heap space to the JVM in which it runs. This is a production-level requirement and can be disabled or corrected during development by editing the script <code>$GLOBUS_LOCATION/bin/globus-start-container</code> (<code>DEF_OPTIONS</code> variable). | ||
+ | |||
+ | :* ''new gHN configuration file for offline use.'' | ||
+ | :: gCore ships with a clone of <code>$GLOBUS_LOCATION/config/GHNConfig.xml</code> called <code>$GLOBUS_LOCATION/config/GHNConfig.client.xml</code>. The latter can diverge arbitrarily from the first to decouple offline and online use of the gHN. | ||
+ | |||
+ | :* ''(optional) configuration of free port range for the gHN.'' | ||
+ | ::Administrators and developers can now specify a <code>portRange</code> environment in <code>$GLOBUS_LOCATION/configs/GHNConfig.xml</code>' (or <code>$GLOBUS_LOCATION/configs/GHNConfig.client.xml</code> if useful). The value of the environment can be specified as in the following example: | ||
+ | |||
+ | <pre> | ||
+ | <environment | ||
+ | name="portRange" | ||
+ | value="60000-61000" <!-- a port range --> | ||
+ | type="java.lang.String" | ||
+ | override="false" /> | ||
+ | |||
+ | </pre> | ||
+ | |||
+ | :: Do note the following: | ||
+ | ::* The configuration does not imply that the ports are actually 'open', only that they can be bound. | ||
+ | ::* The gHN management interface (see below) depends on the existence of this configuration. | ||
+ | ::* The first free port in this range can be obtained by invoking the method <code>getFreePort()</code> om the <code>GHNContext</code>. See the Javadoc documentation for details of the signature. | ||
+ | |||
==== Changes Related to Services ==== | ==== Changes Related to Services ==== |
Revision as of 17:44, 4 May 2009
gCore 0.5.0RC
requires or supports the following changes to code compliant with the 0.4.4 release:
Changes Related to the gHN
- package change in
ResultSet
components
- The inclusion of the
ResultSet
service and related components in gCore has coincided with a refactorisation of their package structure. In particular, fully qualified names that begun withorg.gcube.searchservice
begin now withorg.gcube.common.searchservice
.
- package change in
- new log files and log file location.
- All gCore logs are now located in
$GLOBUS_LOCATION/logs
, whilenohup.out
remains in$GLOBUS_LOCATION
(now regardless of where the$GLOBUS_LOCATION/bin/gcore-start-container
is run from). The gHN's logs remains the same (container.fulllog
,container.log
), but the local services have dedicated log files (ghnmanager.log
,deployer.log
,delegation.log
,rs.log
). Globus logs are now collected in a separate log fileglobus.log
and do not propagate to the contatainer's log files (default log level for globus isWARN
). Developers are recommended to configure service-specific logs during development. For this purpose, the configuration for local services in$GLOBUS_LOCATION/container-log4j.properties
can be used as templates.
- new lower bound on memory requirement for gHNs.
- The gHN now requires the allocation of 1GB of heap space to the JVM in which it runs. This is a production-level requirement and can be disabled or corrected during development by editing the script
$GLOBUS_LOCATION/bin/globus-start-container
(DEF_OPTIONS
variable).
- new gHN configuration file for offline use.
- gCore ships with a clone of
$GLOBUS_LOCATION/config/GHNConfig.xml
called$GLOBUS_LOCATION/config/GHNConfig.client.xml
. The latter can diverge arbitrarily from the first to decouple offline and online use of the gHN.
- (optional) configuration of free port range for the gHN.
- Administrators and developers can now specify a
portRange
environment in$GLOBUS_LOCATION/configs/GHNConfig.xml
' (or$GLOBUS_LOCATION/configs/GHNConfig.client.xml
if useful). The value of the environment can be specified as in the following example:
<environment name="portRange" value="60000-61000" <!-- a port range --> type="java.lang.String" override="false" />
- Do note the following:
- The configuration does not imply that the ports are actually 'open', only that they can be bound.
- The gHN management interface (see below) depends on the existence of this configuration.
- The first free port in this range can be obtained by invoking the method
getFreePort()
om theGHNContext
. See the Javadoc documentation for details of the signature.
- Do note the following: