1. GemStone/S 64 Bit 3.3.7 Release Notes
Overview
GemStone/S 64 Bit™ 3.3.7 is a new version of the GemStone/S 64 Bit object server. This release adds several new features and fixes a number of bugs.
These release notes describe changes between the previous version of GemStone/S 64 Bit, version 3.3.6, and version 3.3.7. If you are upgrading from a version prior to 3.3.6, review the release notes for each intermediate release to see the full set of changes.
The Installation Guide has not been updated for this release. For installation, upgrade and conversion instructions, use the Installation Guide for version 3.3.5.
Supported Platforms
Platforms for Version 3.3.7
GemStone/S 64 Bit version 3.3.7 is supported on the following platforms:
- Solaris 10 and 11.3 on x86
- AIX 6.1 on POWER6 and POWER7 and AIX 7.1 on POWER8
-
Red Hat Enterprise Linux Server 6.4, 6.9, 7.1, and 7.4;
Ubuntu 14.04 and 16.04; and SUSE Linux Enterprise 12, all on x86 - 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)
Supported Windows client platforms are
Note that (deprecated) Solaris/SPARC distributions are available for development and debugging only. Solaris on x86 continues to be fully supported.
For more information and detailed requirements for each supported platforms, please refer to the GemStone/S 64 Bit v3.3.5 Installation Guide for that platform.
GemBuilder for Smalltalk (GBS) Versions
The following versions of GBS are certified with GemStone/S 64 Bit version 3.3.7:
GBS version 8.3
GBS version 8.2
GBS version 5.4.4
For more details on supported GBS and client Smalltalk platforms and requirements, see the GemBuilder for Smalltalk Installation Guide for that version of GBS. Consult the matrices on the website, gemtalksystems.com/products/gbs-vw or gemtalksystems.com/products/gbs-va, for the latest updates.
Changes in this release
Support for Mac/High Sierra file system
The new Apple File System, apfs, is now recognized and handled by GemStone, allowing support for the High Sierra Mac version.
Support for Opportunistic TLS Sockets
New methods have been added that can promote an existing GsSocket to a GsSecureSocket without losing an existing socket connection. The socket connection is transferred from the GsSocket to the GsSecureSocket, which enables STARTTLS behavior.
The following methods have been added to support this functionality:
GsSecureSocket class >> newServerFromGsSocket: aGsSocket
Creates a new instance and initializes it to act as an SSL server socket. Any existing (non-SSL) connection owned by aGsSocket is transferred to the new instance and aGsSocket is effectively closed. No SSL connection is made.
GsSecureSocket class >> newClientFromGsSocket: aGsSocket
Creates a new instance and initializes it to act as an SSL client socket. Any existing (non-SSL) connection owned by aGsSocket is transferred to the new instance and aGsSocket is effectively closed. No SSL connection is made.
Hot standby related changes
Replay of hot standby could lag with high rate of small tranlogs
When a hot standby system has a master repository that produces small tranlogs at a rapid rate, the replay into the slave system could fall behind. (#47566)
The transfer rate in this situation has been improved in several ways:
logreceiver flush interval now configurable
The startlogreceiver utility now accepts the -f <seconds> argument, configuring the flush interval for the logreceiver to flush. The default is 10 seconds.
Previously, the flushing interval was always 2 seconds, which could reduce performance depending on the underlying disk performance, number and size of files.
-f <seconds> Interval in seconds at which the logreceiver flushes the tranlog file.
0 means flush as often as possible (caution: this may be very slow).
-1 disables flushing (file is flushed only when closed).
default: 10 seconds
Configuration Parameter changes
STN_GEM_PGSVR_CONNECT_TIMEOUT
The time in seconds that a remote gem will wait for a connection to a pgsvr on stone's machine to complete.
Runtime equivalent: #StnGemPgsvrConnectTimeout (may only be set by SystemUser)
STN_GEM_PRIVATE_PGSVR_ENABLED
If TRUE, a remote gem will start a private pgsvr process if the attempt to connect to a multithreaded pgsvr on stone's machine fails.
Runtime equivalent: #StnGemPrivatePgsvrEnabled (may only be set by SystemUser)
GEM_PGSVR_USE_SSL is disabled
There are code paths that are broken when the configuration parameter GEM_PGSVR_USE_SSL is set to TRUE. There are thread safety issues in the socket code, making the multi-threaded pgsvr end of the ssl connection unreliable. This parameter has been disabled in this release (fixed in v3.4.1 and later). (#47275)
Restore from backup with missing or corrupted objects
If a backup file has corruption which prevents certain objects from being restored, the restore would terminate with a non-fatal error depending on the specific problem, and the backup file could not be restored. (#47401)
Rather than allowing the backup to be completely unusable, the restore now tolerates some corrupted records and continues to complete the restore. On completion, the restore reports a new fatal error, BKUP_ERR_RESTORE_FAILURE/4152.
If you encounter this error, it is recommended that you find a non-corrupt backup file to restore. However, if you do not have another backup, you can continue to restore the tranlogs.
Added method commitRestoreWithLostData
To commit the restored backup, instead of commitRestore, you must invoke the new method Repository >> commitRestoreWithLostData. After executing commitRestoreWithLostData, you should log in and perform an object audit to determine the extent of the problems, and if possible, attempt to repair the issues.
Automatic commitRestore change
Backups taken from repositories with transaction logs written to /dev/null, or in partial logging mode, normally automatically perform the commitRestore when the backup is completed (since it is not possible to restore tranlogs). If corruption is detected, however, the restore will return BKUP_ERR_RESTORE_FAILURE/4152. The restore is not automatically committed, and you must execute commitRestoreWithLostData in order to commit the restore.
Bugs Fixed
The following bugs in v3.3.6 are fixed in v3.3.7.
Suspended checkpoints resumed after an Epoch GC
When checkpoints have been suspended, if an Epoch GC happened to run during this time window, the suspension was cancelled and checkpoints resumed, without any warning messages in the stone log. If extent copy backups were taking place, which is the usual reason for suspending checkpoints, this could result in the backups being corrupt. (#47133)
Abort may not advance view if not in transaction and many CRs behind
If a session performs an System >> abortTransaction, when the session is outside of transaction, and many commitRecords behind the current, it will not advance it’s view. (#47344)
Extra ShrPcMon processes on heavily loaded system
On a heavily loaded system, in which swapping is taking place, there a race condition in acquiring an exclusive lock on the .LCK file. This can allow multiple ShrPcMonitor processes to be started; the Stone assumes that the earlier one(s) have timed out, and starts another one. Once the Stone connects to one of these ShrPcMon processes, it runs correctly, but the extra ShrPcMon processes remain and use resources. (#46928)
Gems may crash or hang under very low memory conditions
When a machine is almost out of swap space, such that an mmap from reserved memory fails, there are cases where the Gem may crash. (#46848)
Exclusive lock failure can cause tranlog space full error
Creating a new tranlog involves multiple steps; the tranlog is first created, closed, and reopened, then an exclusive lock is requested. If this lock request fails with the error EBADF, the error is incorrectly reported as tranlog space is full. (#47565)
findReferences found references from a large NSC that did not directly contain the object
If a large UnorderedCollection (NSC) contained an object that referenced a search object, but did not contain the search object directly, the results of a findReferences: or fastFindReferences: could still have included the NSC, in addition to the correct referencing object. (#47187)
listInstancesInPageOrder:toFile: reports out of memory
When running listInstancesInPageOrder:toFile:, and there are no instances of the given class, it signalled an AlmostOutOfMemory error. (#47583)
Debugger single-stepping could get stuck
When single stepping through code in a debugger, it was possible for stepping to get stuck and be unable to advance. (#47314)
Remote cache issues
Remote cache connection behavior
The first gem on a remote node triggers the creation of a remote shared cache, and the creation of a page server on the stone's node. The page server on the stone's node is multithreaded and shared between all gems on that remote node.
If a subsequent gem on that remote node fails to connect to the shared page server on the Stone's node within the timeout of 20 seconds, previously it would create a private pageserver. This could result in excessive page servers on the stone's node. (#46946)
Two new configuration parameters have been added to address this behavior:
STN_GEM_PGSVR_CONNECT_TIMEOUT provides control over the timeout specifically for the connection between the remote gem and the page server on the stone's node.
STN_GEM_PRIVATE_PGSVR_ENABLED, if false, prevents the remote gem from starting a private page server if the connection to the shared page server fails or times out. In this case, the remote gem's login would fail.
GEM_PGSVR_UPDATE_CACHE_ON_READ can cause errors for remote logins
When the remote gem configuration parameter GEM_PGSVR_UPDATE_CACHE_ON_READ is set to true, logins from remote gems may encounter the error ’Repository root page is corrupted or contains a disk media defect’. This is related to the requested root page having been flushed from the Stone’s cache. (#47291)
Multithreaded pageserver not shut down after remote cache death
When a remote cache died, the multithreaded page server for that host on the stone’s node was not entirely cleaned up. Entries for the page servers continues to use a slot in the shared page cache monitor client table, although they did not have a process table entry. (#47117)
Cannot change objectSecurityPolicy of a DbTransient object
Instances of Classes that are defined as DbTransient can be persisted, but their instance variable data is not written to disk. When setting the objectSecurityPolicy of a committed DbTransient object, the change to the security policy was not visible outside of the session that made the change. (#46655)
GsHostProcess file descriptor leak
GsHostProcess finalization of in-memory instances did not properly close its three pipes. (#47630)
Accessing large ByteArray with out of range argument errored
Using an out-of-range argument for at: with a ByteArray of size larger than 16273 triggers a corrupt object error, which also prevents further commits in that transaction. (#47131)
topaz truncated byte output
With the setting limit bytes 0, there should be no byte limit on the output. Topaz was incorrectly truncating at 32500 bytes. (#47521)
contentsAndTypesOfDirectory:onClient: incorrect in Unicode Mode
When the repository is in Unicode Comparison Mode (i.e., StringConfiguration is Unicode16), GsFile methods that return file names outside the ASCII range should decode the file names from UFT8 into Unicode strings. The method GsFile >> contentsAndTypesOfDirectory:onClient: did not do this correctly when onClient: was false. (#46894)
GsExternalSession>>lastResult may be incorrect with multiple sessions
GsExternalSession >> lastResult is used to fetch the results of execution. lastResult previously fetched the result from the session that had the most recent previous access, which in an environment with multiple instance of GsExternalSession performing work, could be a different session than the receiver. (#47021)
GsExternalSession resolveResult:toLevel: broken
This method incorrectly used a 1-based offset for a 0-based C array. (#46919)
Security error when browsing implementors
If session methods have been enabled for a user that does not have CodeModification privilege, attempting to browse implementors of any method will trigger a SecurityError. (#47364)
GsSecureSocket did not correctly apply client certificates
There was a bug in the internal code such that when configuring mutual authentication, the method to set CA certificates did not work correctly for client contexts. This did not cause any observed problems, although openSSL documentation indicated this was required. (#47256)