 | Summary: How to upgrade GigaSpaces from version 6.6 to 7.0?
|
Overview
GigaSpaces R7.0 is a major release which includes a number of major themes, such as significantly better administration and monitoring capabilities, optimizations for multi-core environments, highly optimized and flexible local cache, reduced memory footprint, improved deployment model and support for deployment on the cloud.
We have tried to maintain as much as possible a straight forward upgrade process from version 6.6 to the latest release 7.0. This section purpose is to focus on the most common usage scenarios and are not intend to cover the new features and capabilities, therefore the upgrade process is described in the section below using just a few basic steps.
 | How to upgrade from previous GigaSpaces releases (5.x, 6.x) to the latest 6.6 release. Please refer to the  6.6.x Upgrade Guide for more details. |
Best Practices
As a best practice, when upgrading from GigaSpaces 6.6 to GigaSpaces 7.0, unzip the latest version of GigaSpaces 7.0, and port the necessary changes from your 6.6 environment into your new 7.0 environment.
There is no utility which upgrades from GigaSpaces version 6.6 to 7.0. It is recommended to use the GigaSpaces 7.0 distribution as-is.
Note that the product is released with the best out-of-the-box settings for most of the user scenarios in order to achieve stability and performance.
If you do not use the 7.0 distribution As-Is, you will have to compare your existing environment with the 7.0 distribution and re validate the reasons for changing the product out-of-the-box settings. Please contact GigaSpaces customer services for any further clarifications.
Common Steps For Upgrading From R6.6 to R7.0
What is the common user scenario?
In most cases, R6.6. users will unzip the R7.0 distribution and perform the following required changes to start their clusters and enable their clients to connect and operate against the R7.0 clusters.
- Compile your application code using the R7.0 jar files.
- Lookup service Unicast port was changed from 4162 to 4164.
- Putting classes in the shared-lib is no longer required. All processing unit libraries can now be put the lib directory and are now deployed to the processing unit's classloader and not the GSC-wide classloader. This enables better undeploy capabilities, eliminates class sharing between processing units and therefore significantly improves classloading model. In order to maintain backward compatibility, by default, shared-lib jar files are automatically added as if they were placed under the lib directory. It is still a good practice to move them from shared-lib to lib. More information is provided here.
- Custom jars placed under GSHOME/lib/ext (in 6.6) should be moved to GSHOME/lib/optional/pu-common. This will cause them to be loaded in the processing unit class loader and not the common GSC wide class loader. More information is provided here.
- New Users who customized their own scripts calling to GigaSpaces/bin scripts (such as setenv, gs etc.), required to update their classpath to contain the required jar files as described below as well as update the JVM and system property settings.
- The services.config file is no longer used (allowing for much faster bootstrap and simpler configuration). All the services.config settings can be controlled using system properties. The installation comes with a sample services.config.template and renaming it to services.config will cause the Service Grid to take it into account (though we recommended to move to the system properties based configuration).
- Compare your existing environment with the 7.0 distribution and re validate the reasons for changing the product out-of-the-box settings. Common practice is to review the following files:
- Custom schema, override, services.config, pu.xml, mapping, shell scripts files as well as security user credential files.
A new jar structure under the product's lib directory
Simplification of product jars: In an effort to make the initial user experience with the product smoother, we have reduced the amount of jars needed for development and runtime. This is reflected in a new jar structure under the product's lib directory.
The lib directory now contains 3 sub directories as follows:
- lib/required: contains mandatory jars required for compile time and runtime (when running standalone clients and spaces), as follows:
- gs-runtime.jar: includes all classes in former JSpaces.jar, and all jini and service grid jars, i.e. everything needed to run and compile a GS client and Space if you're not using OpenSpaces.
- gs-openspaces.jar: former openspaces.jar
- spring.jar and commons-logging.jar - mandatory if you use OpenSpaces (since it's requires Spring, and Spring requires commons-logging). For applications that use OpenSpaces, altogether 4 jars are required to compile and run a standalone GigaSpaces client or space. For those that do not, a single jar is required. All jars are located under the "lib/required" directory
- lib/optional: contains optional jars and other build products such as openspaces schema files and sources.
- lib/platform: Contains jars which are required by the GigaSpaces runtime environment and tooling. In most cases the user will not need to include any of the jars in this directory in their compile time or runtime classpath. Former lib/ext directory is now under lib/platform/ext.
