1. GemStone/S 64 Bit 3.4.3 Release Notes

Platforms for Version 3.4.3

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

• Red Hat Enterprise Linux Server 6.9 and 7.4, and
  Ubuntu 14.04 and 16.04, and SUSE Linux Enterprise 12, on x86.
  Testing has been done on some earlier Red Hat Enterprise Linux Server 6.x and 7.x versions with the latest security patches.
• Solaris 10 and 11.3 on x86
• AIX 6.1, 7.1, and 7.2
• OS X 10.11.2 (El Capitan) with Darwin 15.2.0 kernel, and
  OS X 10.13.2 (High Sierra), with Darwin 17.3.0 kernel, on x86
  (Mac is supported for development only)

For more information and detailed requirements for each supported platforms, please refer to the GemStone/S 64 Bit v3.4 Installation Guide for that platform.

GemBuilder for Smalltalk (GBS) Versions

GemStone/S 64 Bit version 3.4.3 requires GBS version 8.3 or later for VisualWorks Smalltalk, or version 5.4.4 or later for VA Smalltalk.

The following versions of GBS are supported with GemStone/S 64 Bit version 3.4.3:

VSD Version

The GemStone/S 64 Bit v3.4.3 distribution includes VSD version 5.4. The previous version of GemStone/S, v3.4.2, included VSD v5.3.1.

VSD version 5.4 includes many updates, new features and bug fixes. For details on the changes, see the Release Notes for VSD v5.4.

VSD versions are not tied to GemStone server versions: both older and newer versions of VSD can be used to read statmonitor files generated by both older and newer versions of GemStone/S and GemStone/S 64 Bit.

Updated library versions

The version of lz4 has been updated to v1.8.3.

The version of OpenSSL has been updated to 1.1.1a.

The version of OpenLDAP has been updated to 2.4.46.

The version of Kerberos has been updated to 1.16.2.

Distribution changes

fullBackupTo: and restoreFromBackup: no longer limited to 16 sessions

The multi-threaded backup and restore are initiated with an upper limit on the number of slave sessions (threads). The actual number of threads may be further limited during the course of execution as the backup or restore respects the configured CPU and thread limits. These limits can be adjusted during runtime to further limit or increased the number of threads, but only up to the upper limit set when the operations initialized.

Previously, backup and restore set that maximum limit of the number of threads based on the number of extents, to a number between 2 and 16. With solid-state drives, however, backup and restore may no longer be I/O bound, and that limit of 16 can result in CPU-bound performance. (#47684)

In this version, the maximum thread limit is still by default set, to two times the number of extents, but without the limit of 16. This upper limit can be further increased, before the backup or restore is started, by executing:

SessionTemps current at: #GsOverrideNumThreads put: numThreads

where numThreads is a value between 1 and 4 * the number of CPUs (inclusive).

Note that you should verify that your operation is CPU bound and not I/O bound before raising the threads maximum. Increasing the number of threads will not improve performance if the operation is limited by the performance of disk reads and writes.

The following private methods have been removed:

Repository >> _fullBackupTo:MBytes:compress:

Repository >> _restoreBackups:scavPercentFree:

Ability to configure auto-start for multiple statmonitors

The configuration options STN_STATMONITOR_ARGS, GEM_STATMONITOR_ARGS, and GEM_STATMONITOR_MID_CACHE_ARGS allow you to automatically start statmonitor every time the Stone, remote or mid-level cache, respectively, is started up. These parameters were introduced in v3.4.

Previously, these parameters accepted a single string with statmonitor arguments, or an empty string to not start statmonitor. Now, you may specify a single arguments string or a list of argument strings. Using a list allows you to start multiple simultaneous statmonitor processes with different parameters.

For example, to configure two statmonitor processes on a Stone, one with a 10 second interval and the other with a 60 second, set the configuration parameter something like:

STN_STATMONITOR_ARGS = "-i10 -z -F tenSeconds", "-i60 -z -F sixtySeconds";

copydbf reports version for backup file generated by any other version

While copydbf is intended to be used with dbf files of the same version as the executable, it is useful to use copydbf -i on a backup file generated from an unknown version of GemStone. Previously, this was possible only in some cases, in which the backup file header formats were compatible.

Now, copydbf knows all backup file header formats. Copydbf can be used with backups generated from all versions of GemStone (including 2.x, 3.1.x, 3.2.x, 3.3.x, and 3.4.x, as well as 32-bit GemStone/S 6.7.1), and will return the GemStone version number. Other copydbf functions are limited to compatible versions only. Note that this applies to backup files only; extents and tranlogs are unaffected by this feature.

Setting environment variables from Smalltalk

You may set environment variables in the process for the Gem or client using the following added methods:

System class >> gemEnvironmentVariable: envString put: valString

System class >> clientEnvironmentVariable: envString put: valString

The arguments must be must be either a String or a Unicode7 not larger than 8000 bytes, and NoGsFileOnClient privilege must not be set.

For example:

exec System gemEnvironmentVariable: 'foo' put: 'abc' %

Methods to fetch environment variable values, gemEnvironmentVariable: and clientEnvironmentVariable:, already existed.

Added lock status methods

The following methods have been added:

System class >> systemLocksQuick
Returns an Array of 2 Arrays; the first Array is readLocks, the second is writeLocks. Unlike systemLocks, the details about which sessions hold the locks are not included.

System class >> systemLocksReport
Returns a String that summarizes all of the locked objects. Details about which session holds the locks are not included. For example:

(1 readLocks: 207361(a SymbolDictionary))

(1 writeLocks: 11079425(a SymbolDictionary))

Windows client-side GsFile operations problems with non-ASCII filenames

GsFile is not able to open a Windows client file with a name that contains characters outside the ASCII range, that is, with codePoints over 127. For such filenames, the open:* methods return nil. (#47720).

The fix for this is largely transparent to the user; but there are a number of changes involved to support the correct behavior.

Reclaim configuration parameters revert to speed-optimized values

Values for the ReclaimGem parameters:

#deadObjsReclaimedCommitThreshold  

#objsMovedPerCommitThreshold 

#sleepTimeBetweenReclaimMs 

#sleepTimeWithCrBacklogMs 

#reclaimDeadEnabled 

Are reset following reclaimAll, MFC, or Epoch, to speed-optimized values, and the previous settings are not automatically restored. (#47797)

As of v3.3.x, the values in the GcUser’s UserGlobals are used at startup only; runtime changes to these values are done using methods in System class.

Killing a remote shared page cache risked bringing the Stone down

If a remote shared page cache was killed using SIGTERM (which performs a clean shutdown), there are code paths in which it does not correctly wait for all threads to detach from the Stone's cache. This results in the Stone exit. (#47817)

Stuck session in login cannot be cleaned up

If a UserProfile was configured to record login times, and a problem occurred during login such that this session stopped processing (a stuck session), it may have left the UserSecurityData for the user of this session locked, and the session unkillable. (#47816)

Error gsErrSessionShutdown/4059 not sent to remote clients

An error from the Gem that the session is being terminated, #gsErrSessionShutdown/4059, correctly passes this message to a GCI client on the same node, but does not pass it to a GCI client on a different node. (#47828)

Problems with copydbf -i with files on NFS-mounted disks

With a .dbf file on an NFS-mounted disks, copydbf -i could return an error or report no results, although the file itself is valid. (#47732)

Extents on CIFS filesystems on Linux do not work

Attempting to create or mount an extent that is on an CIFS file system does not work, and has been disallowed. (#47718)

fullBackupCompressed data file size based on uncompressed size

The MBytes: limit argument to multiple file fullBackupCompressed was applied to the uncompressed data size. This resulted in smaller files being written for all files except the last, and the large remainder of the backup being written to the single final file. (#47801)

Gem crash with very large GEM_MAX_SMALLTALK_STACK_DEPTH on Linux or Solaris/x86

When GEM_MAX_SMALLTALK_STACK_DEPTH is very large (over 35000) then an AlmostOutOfStack signal may result in a Gem SEGV, for Gems running on x86_64 processors. Now, this configuration is automatically limited to no more than 35000 on these platforms. (#47753)

WriteSet issues with nested transactions

When a nested transaction is started, the writeSet could be overstated, including objects that were not modified by the outer transaction. This persisted through the commit of the nested transaction. Also, attempts to modify an invariant object may have put the invariant object in the write set before signalling the Error that modification was not allowed.(#47799)

listInstances:limit: limit not applied to instances in memory

Repository>>listInstances:limit: finds both persistent instances and instances in memory, returning no more results than the limit specified. However, this limit was not being applied to instances in memory, so the results could exceed the limit. (#47806)

Private internal objects can error during commit conflict resolution

During reduced-conflict (RC) resolution after a commit conflict, involved objects are selectively aborted. There were cases in which this was done on instances of private internal classes, such as NscBagLeaf, which resulted in a doesNotUnderstand error. (#47796)

Object and page audit errors after restore of NonTranloggedGlobals

When a repository is using NotTranloggedGlobals, and performs a backup and restore from logs, there are some circumstances in which OOPs end up neither allocated nor on the free OOP list. This causes object and page audit to report errors. (#47681)

Stone checkpoint state not updated quickly when checkpoint work done

During a checkpoint, the Stone waits for the AIO page servers to complete the actual work involved in the checkpoint. The Stone was not checking often enough that the checkpoint work is done, resulting in a checkpoint appearing to take a minimum of 10 seconds to complete. (#47769)

Statmonitor subsecond sampling generates incorrect timestamps

In most cases, the timestamps that statmonitor collects from GemStone are rounded to the nearest whole number of seconds before being recorded. This allows them to be easily understood with the VSD display. With sub-second timestamp intervals, however, the seconds field should be truncated, not rounded. This rounding resulted in timestamps that were incorrect by up to 1 second. Since VSD skips out of order timestamps, the charts displayed by VSD did not include all samples. (#47768)

Class Definition issues

Indexing issues

UTC offset in header has incorrect sign

Information in the header on the start time/date of a GemStone process now includes UTC offset information. However, the sign of the value is inverted. (#47712)

Upgrade created new version of TimeZone class

Running the image upgrade causes a new version of the TimeZone class to be unnecessarily created. (#47727)

Using 3.4 shared libraries with 3.4.2 was allowed but could hang

The library compatibility checks were not updated for 3.4.2, so that 3.4 shared libraries could be used to login. Some operations, such as those using GsFile, would hang with this mixed configuration. (#47823)

GsFile user action invocation with invalid name on client

GsFile is implemented internally in user actions (for historical reasons). If the private API for client-side operations is used with an invalid user action name in an RPC sessions, it causes errors and stack overflow. (#47825)

Integer printing broken on Windows client 64-bit topaz

GemStone provides both 64 bit and 32 bit topaz executables with the Windows client. In 64-bit topaz, printing of Integers is incorrect. (#47733)