[Glass] Error 4039 "max processes on shared cache" on login with only 1–3 sessions active — Community 20-session limit + linked GCI

[Tariq Hamid]

Hello,

We run a Pharo (14) → GemStone/S 64 Bit 3.7.5 web application (Seaside via
a Pharo-side GCI bridge) on a single Linux host, Community Edition (Stone
Session limit: 20). The app serves fine, but any second login that runs
during a deploy fails with:

[GemStone Login Error]  Error Number: 4039
Login failed: the maximum number of users are already logged in,
login would exceed max sessions configuration or max processes on shared
cache

The puzzling part: this happens even when almost nothing is connected.
After a full clean restart (stopstone/startstone + startnetldi, and pkill
pgsvr to clear stragglers), with the stone reporting only the primary app
session active (gslist shows j + one app), a single additional linked-GCI
login for our deploy step still gets 4039. So it does not appear to be
genuine session exhaustion — 17+ of the
20 session slots are free.

Our reading is that it is the "max processf the error, not the
session-count half.Relevant config from the stone startup log:

SESSION CONFIGURATION: maximum number of concurrent sessions is 20
WARNING: STN_MAX_SESSIONS = 32767 exceeds AX_SESSIONS = 20
SHR_PAGE_CACHE_NUM_PROCS       = 72
SHR_PAGE_CACHE_NUM_SHARED_COUNTERS = 1900
SHR_PAGE_CACHE_SIZE_KB         = 500000
GEM_RPC_USE_SSL                = TRUE

system.conf explicitly sets STN_MAX_SESSIOby the license) and
SHR_PAGE_CACHE_SIZE_KB= 500000; SHR_PAGE_CACHE_NUM_PROCS = 72 appears to be
auto-derived.

Questions:

1. Is SHR_PAGE_CACHE_NUM_PROCS = 72 derived from the clamped
STN_MAX_SESSIONS = 20, or from the configured
32767? Could the 32767→20 clamp be leavingtable sized inconsistently,
socache-process slots exhaust before the 20 session slots do?
2. With linked GCI (libgcilnk), how many sdoes a single login actually
consume vs anRPC login? We use linked GCI both for the running app and for
the deploy-time login that fails — could linked
logins be consuming multiple cache slots ehe deploy-time login to RPC avoid
the "maxprocesses on shared cache" path?
3. Is explicitly setting SHR_PAGE_CACHE_NUing the 20-session budget with
generousheadroom) in system.conf the right fix, and what is the recommended
relationship between SHR_PAGE_CACHE_NUM_PROCS, STN_MAX_SESSIONS-GCI clients
on Community Edition?
4. Does GEM_RPC_USE_SSL = TRUE add to the cache-process/attachment cost per
login?
We would rather set the config correctly than keep bouncing the stone. Any
guidance on the intended sizing of SHR_PAGE_CACHE_NUM_PROCS relative to the
lhether STN_MAX_SESSIONS = 32767 beingclamped is itself the trigger — would
be much appreciated.

Thanks,
Tariq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20260725/69e41f53/attachment.htm>