Summary: How to upgrade GigaSpaces from version 7.0 to 7.1? Overview | Best Practices | Common Steps For Upgrading From R7.0 to R7.1

Overview

GigaSpaces R7.1 is a major release which includes a number of major themes, such as improved querying capabilities, faster transaction processing, distributed troubleshooting capabilities and better replication resiliency.

We have did our best to ensure the smoothest possible upgrade process from version 7.0 to the 7.1 release. The purpose of this section is to focus on the most common upgrade scenarios. It is not intend to review or describe the new features in version 7.1 (these are described here).

For upgrade instruction from previous versions to version 7.0 please refer to this page

Best Practices

As a best practice, when upgrading from GigaSpaces 7.0 to GigaSpaces 7.1, unzip the latest version of GigaSpaces 7.1, and port the necessary changes from your 7.0 environment into your new 7.1 environment.
There is no utility which upgrades from GigaSpaces version 7.0 to 7.1. It is recommended to use the GigaSpaces 7.1 distribution as-is.
Note that the product is released with the optimal settings for the most common user scenarios in order to achieve stability and performance.
If you do not use the 7.1 distribution as is, you will have to compare your existing environment with the 7.1 distribution and re validate the reasons for changing the product out-of-the-box configuration. Please contact GigaSpaces customer services for any further clarifications.

Common Steps For Upgrading From R7.0 to R7.1

In most cases, R7.0. users will unzip the R7.1 distribution and perform the following required changes to start their clusters and enable their clients to connect and operate against the R7.1 clusters.

1. Compilation: Compile your application code using the R7.1 jar files.
2. Spring 3 Support: R7.1 includes Spring 3.0.1. In this release of Spring, it does not deliver a unified, all-inclusive spring.jar file, but rather a number of jars corresponding to the various Spring framework modules. All of the Spring jars required to compile and run GigaSpaces application can be found under <GigaSpaces 7.1 root>/lib/required. The GigaSpaces runtime components (GSA, GSM, GSC, etc.) have been updated to reflect this change, so there's no need to change them. However you will need to change the classpath of your development environment or any external application that accesses GigaSpaces to reflect this change. Simply make sure your application includes all the jars under <GigaSpaces 7.1 root>/lib/required.
3. Jetty 7.1.4 Support: R7.1 includes Jetty 7.1.4. some of the packages in this version has been changed, please refer to Web Jetty Processing Unit Container page for more information.
4. Replication redo log changes in 7.1: R7.1 includes a number of changes to the replication redo log which is responsible for accumulating the changes that should be replicated from one space instance to another or from a space instance to the mirror service.
   Some of the defaults of the redo log have been modified as a result of this change. If you have not modified any setting that is related to the redo log, the 7.1 default should not be modified. If you have done some changes, make sure you read this page and validate the necessity of these changes before porting them to 7.1. Please contact the GigaSpaces support team if you need further guidance.
   Also note that the Exception hierarchy in 7.1 is slightly different as a result of this change. In XAP 7.1 we've introduced a new type of exception named RedoLogCapacityExceededException. This exception is thrown when the redo log maxed out its planned capacity, and indicates that operations are blocked until the replication mechanism manages to reduce the redo log size and flush the pending replication packets to the replication target.
   Also note that the existing SpaceMemoryShortageException and this exception now have a common super class, ResourceCapacityExceededException and you can use this class to handle both cases when it makes sense.
5. 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 new Spring jar files under the <GigaSpaces 7.1 root>/lib/required directory.
6. Compare your existing environment with the 7.1 distribution and re validate the reasons for changing the product out-of-the-box settings. Common practice is to review the following files:
   1. Custom schema, override, services.config, pu.xml, mapping, shell scripts files as well as security user credential files.
7. Multiple Operations Exception Handling - readMultiple,takeMultiple and clear operations exception handling was changed in 7.1 to throw an operation specific runtime exception. These exceptions support partial failure.
   So any code that relied on these operations to throw a specific exception - for example TransactionException, now needs to be changed to catch the operation specific exception:
   1. readMultiple - on any failure ReadMultipleException is thrown. Can be disable by providing IGNORE_PARTIAL_FAILURE modifier.
   2. takeMultiple - on any failure TakeMultipleException is thrown. Can be disable by providing IGNORE_PARTIAL_FAILURE modifier.
   3. clear - on any failure ClearException is thrown.
8. Cleaning up resources when running space instances or space clients in a standalone Java application of within a hosted environment (e.g. an external JEE application server): in version 7.0 and earlier, the communication resources used by space instances and space clients were automatically shutdown by the GigaSpaces runtime when used in a standalone/hosted environment. However this behavior caused some issues related to the timing of the shutdown and in some cases prevented asynchronous operations (such as getting back the result of a Task's execution) from being completed successfully. In version 7.1 this behavior has been changed, and the GigaSpaces runtime no longer shuts down the communication resources implicitly. The user should make sure to shutdown these resources explicitly when GigaSpaces is no longer used (e.g. when the application is undeployed from the application server). If the JVM is shut down the user does not need to do explicitly shut down the communication resources.
   Note that if you're using the GigasSpaces runtime environment to run your GigaSpaces application this is irrelevant.
   For more information please refer to the LRMIManager class.