BadTooManySessions

BadServer limits

What you actually see

New clients cannot connect while existing ones keep working, and the failure appears at CreateSession rather than at the socket or certificate stage.

Why it happens

• Orphaned sessions from a reconnect loopA client whose handshake times out retries, and the retry creates a fresh session while the original is orphaned and still counted until its timeout expires. This is a positive-feedback loop: the more the server struggles, the more orphans accumulate, and the limit is reached with almost no real clients attached.
• A low session limit on an embedded serverPLC-embedded and device servers often allow only a handful of sessions - single digits is common. Two engineering tools, a SCADA connection and a historian can exhaust that budget with nothing pathological happening at all.
• One session per tag group or per threadCollector configurations that create a session per device, per polling group or per worker multiply session count needlessly. A single session can carry many subscriptions; the practical pattern is one session per client per endpoint.
• Long session timeouts plus crashing clientsIf a client process is killed, its session lingers for the whole revised session timeout. A ten-minute timeout and a client that crashloops every thirty seconds will pin the session table at its ceiling.
• Connect storm at plant startupWhen power returns, every client dials at once. Session establishment is CPU-bound on the RSA handshake and chain validation, so the server serialises behind cryptography, handshakes time out, and clients retry - producing both this code and BadServerTooBusy.

How to fix it

In diagnostic order: work down, do not skip ahead.

1. Count the live sessions on the serverBrowse Server_ServerDiagnostics_SessionsDiagnosticsSummary and read SessionDiagnosticsArray. Each entry carries the client name, ApplicationUri, session name and last-contact time - that is how you identify the orphans and their owner.
2. Kill the orphans, then look at the ownerShorten the revised session timeout on the server so dead sessions age out faster, or use the vendor's disconnect action. Then fix the client that produced them; leaving it running just refills the table.
3. Consolidate sessions per clientReconfigure collectors to one session per endpoint with multiple subscriptions rather than one session per group. Also minimise the number of distinct publishing intervals, since each distinct interval forces another subscription and encourages engineers to split into more sessions.
4. Stagger client connectsAdd a randomised delay and bounded exponential backoff to client startup. Staggering connects is the single most effective client-side measure against connect storms, and it stops the retry loop that manufactures orphans.
5. Raise the limit only if the hardware supports itMaxSessionCount is configurable on most software servers. Raise it only after checking CPU headroom during handshakes; on an embedded server the limit usually reflects real memory constraints and cannot be moved.

Where it shows up, by tool and stack

What it looks like in the log

CreateSession rejected: BadTooManySessions (current=10, max=10)
Session table full; refusing new session from urn:collector01:MyCollector
Client retry after handshake timeout created session 47; previous session 46 orphaned

Confirm the fix

Watch SessionDiagnosticsArray shrink to the number of clients you actually expect, then connect one new client with UaExpert and confirm CreateSession succeeds immediately.

Stop it happening again

Cap sessions per client in configuration standards, use bounded exponential backoff with jitter everywhere, and alarm on the live session count crossing a threshold below the server limit rather than on the refusal itself.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.