1. GemStone/S 64 Bit 3.2.16 Release Notes

Platforms for Version 3.2.16

GemStone/S 64 Bit version 3.2.16 is supported on the following platforms:

• Solaris 10 and 11 on SPARC
• Solaris 10 on x86
• AIX 6.1 and AIX 7.1
• Red Hat Linux ES 6.4 and 6.5, Ubuntu 12.04 and 14.04, and SUSE Linux Enterprise 12, on x86
• Mac OSX 10.9.5 (Mavericks), with Darwin 13.4.0 kernel, on x86 (Mac supported for development only)

Note that Ubuntu 12.04 end-of-life is imminent, and that Solaris on SPARC support is being deprecated and will be available for development only. Solaris on x86 will continue to be fully supported.

GBS Versions

The following versions of GBS are supported with GemStone/S 64 Bit version 3.2.16.

VSD Version

The GemStone/S 64 Bit v3.2.16 distribution includes VSD version 5.3, while the previous version, v3.2.15, included version 5.1.3. There have a been significant changes in versions 5.2 and 5.3. In particular, 5.2 improves support for working with multiple files, and v5.3 contains important changes in managing the VSD configuration and in monitoring.

For details on the changes, see the release notes for versions 5.2 and 5.3, accessible at gemtalksystems.com/products/vsd/versions/.

Community Edition Keyfile for Linux and Darwin

For some time, GemStone distributions on certain platforms have included a limited starter keyfile, intended primarily for use with Seaside/GLASS/GsDevKit applications and therefore located under the $GEMSTONE/seaside directory. These keyfiles are suitable for evaluation.

In v3.2.16, on Linux and Darwin, the GemStone distribution includes a starter keyfile under $GEMSTONE/sys, with the name community.starter.key. If there is no keyfile at the location $GEMSTONE/sys/gemstone.key, then the stone will look for a keyfile $GEMSTONE/sys/community.starter.key and use that for startup.

If the configuration parameter KEYFILE refers to an invalid file, or a file other than $GEMSTONE/sys/gemstone.key that does not exist, then the stone will not use the starter keyfile and will fail to start.

Note that the starter keyfile does not have permissions for GBS, GemConnect, or GBJ; if you set up a new installation and do not set your license keyfile, the stone will now start rather than failing with an error. Operations such as attempting to login from GBS, for example, will fail.

The keyfile that is distributed under the seaside directory continues to be included in the distribution in the old location on Linux and Macintosh, in addition to the new keyfile.

Improved handling of CR backlog on stone startup.

When the stone recovers after an unexpected shutdown, and there is a large number of commit records to process, it can delay making the stone available for users for a significant period of time.

In this release, the way recovery from a commit record backlog is handled on startup has been modified to reduce this delay. Now, while some critical work is done during the initial recovery and startup, the final commit record processing and disposal is now done in the background, after the stone is available to users.

The startup messages in the stone log under these circumstances have been updated to log the new behavior.

Additional printing for GCI errors

When a GCI protocol error occurs, GemStone will now print the recent GCI calls and associated packets to allow diagnosis.

gslist "exe deleted" status

When a GemStone distribution is replaced while netldi, stone, or cache are running, gslist described these as killed; now it reports a new status "exe deleted".

Increased limit for GsSocket read:into:startingAt:

The read limit for the method GsSocket >> read:into:startingAt: was previously 10000000 (10MB), now it is 500000000 (500MB)

Idle Gems not terminated by STN_GEM_TIMEOUT

The configuration parameter STN_GEM_TIMEOUT is designed to terminate gems that have had no interaction with the stone for some period of time. There was a logic error that prevented the check from running, with the result that idle gems were not terminated. (#46723)

Gem hot hangs when repository oop high water mark exceeded 4 billion

When the repository’s oop number high water mark exceeded 4 billion, a number of operations that scan the entire repository, including backup, restore, MFC and write set union sweep as well as multithreaded scan operations, could hang. (#46252).

Gem crash due to excessive recursion in MFC

There was an optimization in the multithreaded MFC that performed a recursion; it was possible for excessive recursion to occur which resulted in running out of C stack space. This optimization was determined to provide very little value and has been removed. (#46194)

Infinite loop if gemstone.hostid exists but not readable

Each host with a GemStone server node finds or creates a file /opt/gemstone/locks/gemstone.hostid to identify the host. If this file existed, but was not readable by a process such as linked topaz, the process hung. (#46219)

listReferences failed to find object in large IdentityBags/Sets

If an object is in an IdentityBag or IdentitySet with more than about 1015 or 2030 elements, respectively, a listReferences: or fastListReferences: operation did not detect the reference. (#46645)

Incorrect tranlog entries for insert into a large byte object

When a large object is modified, changes to leaf objects composing it must be tranlogged. In the case of byte objects (such as Strings), insert operations did not correctly log the changes, so after restore the state could be inconsistent. (#46474)

changeClassTo: disallowed for NSCs with fewer named instance variables

When changeClassTo: is requested, and the number of named instance variables is fewer than that of the original class, the values in the removed named instance variable slots may be moved to unnamed instance variables. This caused object corruption for instances of IdentityBag, and data corruption for instances of IdentitySet. (#46475 )

AES encryption with wrong argument size handled incorrectly

Encryption methods such as aesEncryptWith256BitKey: require specific sizes for the key and salt. If an incorrect salt size was provided, it crashed. (#46358)

gslist -m did not report information on non-netldi process

gslist -m reports information on remote servers; however, it incorrectly only reported information on NetLDI processes, omitting information on Stone and other processes. (#46262).

GsNMethod instance variables not protected

Some instance variables are unsafe to access directly due to the way they are stored in memory. These accesses are protected; however, instVarAt: was not reimplemented to provide safe access. This method has been added to GsNMethod. (#46405)

Resuming after AlmostOutOfMemory

When the Gem is almost out of memory it signals an Admonition, #6013, AlmostOutOfMemory/ #rtErrSignalAlmostOutOfMemory. This can be handled, the cause of the out of memory corrected, and processing resumed. To avoid getting stuck when no memory can be freed, after two unsuccessful attempts it will now signal an Error, #2517, #errAlmostOomPending. (#44514)

Indexing bugs

upgradeSeasideImage failed as a result of recently added class

After additions of GLASS/Seaside/GsDevKit class NumberParserGsDevKitIssue75Test, the upgradeSeasideImage step failed. (#46217)

Object >> storeOn: failed for large strings

The method Object >> storeOn: had a typo that was exposed for large strings. (#46381)

_tempObjSpaceMax can return negative values on large TOC

When GEM_TEMPOBJ_CACHE_SIZE was configured to larger than about 2800000, the method System >> _tempObjSpaceMax returned a negative value. (#46384)