Bug 44840

Bug: 44840

Impact:

Informational

Product:

GemStone/S 64 Bit

Versions:

3.1.0.6, 3.1.0.5, 3.1.0.4, 3.1.0.3, 3.1.0.2, 3.1.0.1, 3.1

Platform:

All Platforms

Fixed In:

3.2

restoreFromBackup: can fail with "Error during login:".

The new version of restoreFromBackup: spins up X threads to speed up the operation, where X is the number of extents in the repository.  Each of these threads are treated like a separate GemStone session, and will need to login and gain access to the shared page cache just like any other GemStone session.

If X exceeds the number of available sessions (limited by STN_MAX_SESSIONS) or the number of SPC slots (limited by SHR_PAGE_CACHE_NUM_PROCS), the operation will fail with the error:

  -----------------------------------------------------
  GemStone: Error         Fatal
  Error during login:
  Error Category: 231169 [GemStone] Number: 4147  Arg Count: 0 Context : 20 exception : 20

Note that additional information is printed out in the gem log (or to stdout for a linked topaz session) that can indicate which parameter is causing problems.

If constrained by STN_MAX_SESSIONS you will see messages of the form:

PagesInOt-XX: Login error: Login failed:  the maximum number of users is already logged in.
...
slave thread login error PagesInOt-XX: Login error: Login failed:  the maximum number of users is already logged in.


If constrained by SHR_PAGE_CACHE_NUM_PROCS you will see messages of the form:

PagesInOt-XX: Login error: Unable to attach to shared cache
...
slave thread login error PagesInOt-XX: Login error: Unable to attach to shared cache

Note that most sites use the default value of -1 for SHR_PAGE_CACHE_NUM_PROCS, which calculates a reasonable value based on the setting of STN_MAX_SESSIONS, but which *might not* be large enough to cover the additional threads from restoreFromBackup:.

Workaround

Depending on the error message seen in the gem log / linked topaz output, increase the setting of STN_MAX_SESSIONS or SHR_PAGE_CACHE_NUM_PROCS.  If using the default setting of SHR_PAGE_CACHE_NUM_PROCS, you can just increase STN_MAX_SESSIONS rather than trying to calculate a reasonable value as described in the comments for SHR_PAGE_CACHE_NUM_PROCS in the configuration file.