1. GemStone/S 64 Bit 3.5.6 Release Notes

GBS version 8.5

GBS version 8.4

GBS version 5.4.6

GBS version 5.4.5

Windows 7 reached end of life in January of 2020. While GemTalk continues to test on and support GemStone clients on Windows 7, it is no longer considered fully certified.

For more details on supported GBS and client Smalltalk platforms and requirements, see the GemBuilder for Smalltalk Installation Guide for that version of GBS.

Added LdapDirectoryServer methods

The following methods have been added:

LdapDirectoryServer >> validatePassword: aPassword forUserId: aUserId withBaseDn: aBaseDn filterDn: aFilterDn
Use the receiver LdapDirectoryServer to validate the given userId and password. See the method comments for examples on using this method for validation.

LdapDirectoryServer class >> basicNewWithUri: uri bindDN: aBindDn password: password baseDN: baseDn tlsCaCert: caCert tlsCert: cert tlsKey: key tlsReqCert: aSymbol
Creates a new instance of the receiver but does not add it to the list of LdapDirectoryServer objects used to authorize logins.

LdapDirectoryServer class >> newWithUri: uri bindDN: aBindDn password: password baseDN: baseDn tlsCaCert: caCert tlsCert: cert tlsKey: key tlsReqCert: aSymbol
Creates a new instance of the receiver and adds the resulting object to the list of LdapDirectoryServer objects used to authorize logins.

LdapDirectoryServer class >> testConnectionToServer: uri bindDN: aBindDn password: password baseDN: baseDn tlsCaCert: caCert tlsCert: cert tlsKey: key tlsReqCert: aSymbol
Attempts to perform a bind using aBindDn and password to the LDAP server specified by uri. Also sets the TLS credentials, if those arguments are not nil. Returns true if the connection was successful, otherwise returns false.

Added configuration parameter STN_TRAN_INCREMENTAL_LOGGING

To manually control incremental tranlogging, the configuration parameter STN_TRAN_INCREMENTAL_LOGGING has been added. The default is true, providing behavior from previous releases. When false, operations such as changes to collections that are usually incrementally logged are instead logged in full. This will result in larger tranlog volume.

STN_TRAN_INCREMENTAL_LOGGING
FALSE shuts off the incremental logging of additions or deletions to nodes of large objects, with side effect of more bytes written to tranlogs.
Default TRUE.

logsender may read incomplete tranlog records

In a hotstandby system, when the logsender transmit records to the logreceiver, there is the possibility that while the write operation completed, the disk fsync was not complete, and so the record read from disk by the logsender and sent to the logreceiver may be incomplete. (#49449)

A related problem still exists in this version, in the case where the logsender is not connected to the master Stone (using the -s flag), and therefore has to rely on disk file writes to detect when a new record is available. A logical record may cross a file system block boundary, and this is not detected by the logsender’s disk file checks. It is strongly encouraged to use the -s flag to avoid this risk; the Stone tracks the logical record boundaries and provides this information to the logsender.

logsender compression buffer too small

There was a chance that the logsender buffer for tranlog compression was too small, resulting in an overflow. (#49501)

Cumulative algorithm changes in Symbol GC

Symbol Garbage Collection has undergone a number of internal changes in the algorithm used to ensure behavior is correct for large sets of dead symbols in active repositories, with additional validation on large customer repositories.

Note that the documentation describing the internal algorithms used is no longer correct with respect to current behavior.

Symbol GC may have collected referenced Symbols

A Symbol whose only reference is from an object in the possible dead set, may be garbage collected even if the referencing object is voted to stay alive rather than being promoted to dead. (#49339)

Symbol GC slow with many dead symbols

When Symbol GC found a very large number of possible dead symbols, the write set union sweep became unreasonably slow. This was a result of the possibleDeadSymbol structure containing large collision buckets; the objects referenced from the collision buckets were being read, which is unnecessary, since all contained objects would be symbols. (#49504)

Reclaim log entries omitted

Entries providing information on reclaim activity, after the first entry, were not printed to the ReclaimGem’s log file. (#49388)

Warnings on range test incorrect

Some out of range warnings in the ReclaimGem log displayed incorrect information. (#49396).

On startup, verbose logging was true

On GcGem startup, the values used for the configuration parameters #reclaimVerboseLogging and #adminVerboseLogging were true, regardless of the value previously set. (#49389)

More information printed when reclaimVerboseLogging is true

With #reclaimVerboseLogging set to true, additional information on individual reclaims is now printed in the reclaim log. #(49409)

LDAP did not work for processes in setuid mode

If the process is in setuid mode (that is, the real and effective UNIX userIds of a process are not the same), LDAP does not read environment variables, nor files in the $HOME directory, and thus was not able to set all required information to connect to an LDAP server. (#49498)

With a setuid mode process, such as a Gem with the s bit set, you will need to use the new LdapDirectoryServer tls* instance variables within GemStone Smalltalk to set the certificate requirement, and certificates if necessary, that allow connection to the LDAP server. See LdapDirectoryServer now supports TLS options.

GemStone's LDAP library did not correctly set directory for ldap.conf

GemStone's LDAP library, libldap-N.N.N-64.so, looked for ldap.conf in the installation directory, $GEMSTONE, which did not follow LDAP conventions. (#49515)

Now, it will look for /etc/openldap/ldap.conf. This setting can be overridden by environment variables, or by files .ldaprc or ldaprc. Note that the specific LDAP search sequence is distribution dependent; this is the RedHat/CentOS convention. See the ldap.conf man page for your distribution for details.

LDAP did not support reset of TLS credentials

The binding to TLS credentials in LDAP could not be done more than once; so changing TLS credentials required restarting the process. (#49499)

Stone did not auto-start statmonitor early enough when in recovery

When STN_STATMONITOR_ARGS is set, the Stone starts statmonitor on startup; which is possible as soon as Stone connects to the shared page cache. However, when the Stone was in recovery (after an unclean shutdown), it did not start statmonitor until recovery was complete, which meant no statistics information was available on the recovery itself (#49442)

GEM_STATMONITOR_ARGS did not start statmonitor

When the configuration parameter GEM_STATMONITOR_ARGS is specified, statmonitor should automatically be started on remote node on which a Gem is running. Statmonitor was not successfully starting. (#49463).