Tomcat activeSessions growing without plateau: the session leak

The chart shows activeSessions from Catalina:type=Manager,host=localhost,context=/<app> climbing in a near-straight line. No plateau. You restarted Tomcat this morning, and by midafternoon the count is already back to where it was before the restart. Sessions are being created faster than they expire, and with the default 30-minute session-timeout, expiry is slow enough that the slope looks gentle until you compare it to the request rate.

This is a session leak, not a traffic spike. A spike produces a step up that plateaus at roughly peak_creation_rate * session_timeout. A leak has no plateau: the line keeps rising after traffic drops because sessions that should have expired are still pinned, or because new sessions are being minted faster than the background expiry loop can clear them.

The end state is mechanical. Tomcat’s default StandardManager keeps sessions as in-memory objects on the heap. Monotonic session growth is monotonic heap growth. Eventually the post-GC heap baseline rises to the point that Full GCs dominate execution, throughput collapses, and the JVM either throws OutOfMemoryError or livelocks. The session leak is rarely the incident you get paged for; the GC death spiral is. By the time you see the spiral, the session chart has been telling the story for hours.

The diagnostic path: confirm the leak is real (not a slow-expiry lag), then bucket the cause into one of three: the application never invalidates, expiry is blocked, or session creation is pathological.

What this means

A Tomcat session under StandardManager is a StandardSession held in a ConcurrentHashMap keyed by session ID. It exists from createSession() until expire() runs. Expiry is triggered in three ways:

1. The container background process expires sessions whose lastAccessedTime + maxInactiveInterval is in the past. With default settings this runs roughly every minute: the engine background thread fires every 10 seconds and the session manager runs the expiry check on every sixth pass.
2. Application code calls HttpSession.invalidate().
3. The webapp is undeployed, expiring every session for that context.

If activeSessions is rising without plateau, one of these is failing to keep up with creation. Read the Manager MBean directly. activeSessions is not in the Manager status XML; you need JMX. Adjust the host and context in the object name to match your deployment.

# Read active and expired session counts for the ROOT context
echo 'get -b Catalina:type=Manager,host=localhost,context=/ activeSessions expiredSessions' | \
  java -jar jmxterm.jar -l localhost:9090 -n -v silent

Pair activeSessions with expiredSessions. The cumulative expiredSessions counter tells you whether expiry is happening at all:

• expiredSessions is rising, but activeSessions still climbs: expiry is working, but creation is outpacing it. Look at the creation side (bots, JSP defaults, login churn).
• expiredSessions is flat or barely moving while activeSessions climbs: expiry is broken or blocked. Look at the background thread, listener deadlocks, or a misconfigured timeout.

The rejectedSessions counter tells you whether maxActiveSessions is set. With the default of -1 (unlimited), there is no backstop; the count climbs until the heap runs out. rejectedSessions > 0 means a limit is configured and Tomcat is shedding new session creations. Users see errors, but the heap is protected.

flowchart td
    A[activeSessions rising, no plateau] --> B{expiredSessions rising too?}
    B -- Yes --> C[Creation outpaces expiry: bots, JSP session=true, login churn]
    B -- No --> D[Expiry broken: jstack background thread]
    D --> E{Thread blocked in listener?}
    E -- Yes --> F[HttpSessionListener deadlock]
    E -- No --> G[Verify session-timeout in web.xml]
    C --> H[Confirm slope drops after fix]
    F --> H
    G --> H

Common causes

Quick checks

All read-only except the heap dump. Run these before changing anything. If multiple Tomcat instances run on the host, target the correct PID instead of relying on pgrep.

# Per-context session attributes via JMX
echo 'get -b Catalina:type=Manager,host=localhost,context=/ activeSessions expiredSessions rejectedSessions sessionMaxAliveTime sessionAverageAliveTime' | \
  java -jar jmxterm.jar -l localhost:9090 -n -v silent

# Confirm expiry is actually happening: sample twice, 5 minutes apart
for i in 1 2; do
  echo 'get -b Catalina:type=Manager,host=localhost,context=/ expiredSessions' | \
    java -jar jmxterm.jar -l localhost:9090 -n -v silent
  sleep 300
done

# Heap pressure correlate: post-GC old gen baseline
jstat -gcutil $(pgrep -f 'catalina.startup.Bootstrap') 1000 5

# Thread state of the container background processor
jstack $(pgrep -f 'catalina.startup.Bootstrap') | \
  grep -A 5 -E "Catalina-utility|ContainerBackgroundProcessor"

# Top client IPs by request volume (proxy for bot/crawler activity)
awk '{print $1}' /var/log/tomcat/localhost_access_log.$(date +%Y-%m-%d).txt | \
  sort | uniq -c | sort -rn | head

# To check JSESSIONID cookie presence per request, the access log Valve must
# include %{Cookie}i in its pattern. The default pattern does not log cookies.

# Find JSP pages that do not opt out of session creation
grep -rni '<%@.*page.*session' $CATALINA_BASE/webapps/ 2>/dev/null | grep -v 'session="false"'

# Check configured session timeout and any per-context session limits
grep -A 2 'session-config' $CATALINA_BASE/conf/web.xml
grep -rni 'session-timeout\|maxActiveSessions' \
  $CATALINA_BASE/conf/ $CATALINA_BASE/webapps/*/WEB-INF/web.xml 2>/dev/null

How to diagnose it

1. Confirm the slope is real, not a traffic artifact. Plot activeSessions alongside the request rate. A leak has the session line rising while the request rate is flat or dropping. A pure traffic spike plateaus within roughly one session-timeout of the traffic peak.

2. Confirm expiry is happening. Sample expiredSessions twice, a few minutes apart. If the counter does not move at all, expiry is blocked; go to step 4. If it moves but activeSessions keeps rising, expiry is overwhelmed; go to step 3.

3. If expiry is overwhelmed, identify the creation source. The fastest signal is the access log. Group requests by client IP and user-agent and count how many arrive without a JSESSIONID cookie. Crawlers that ignore cookies are the classic offender; each request mints a new session. If the application uses JSPs, verify that pages not needing a session have <%@ page session="false" %>.

4. If expiry is blocked, take a thread dump immediately. The container runs session expiry on a background thread. A thread dump showing that thread BLOCKED inside an HttpSessionListener.sessionDestroyed call means listener code is holding a lock or deadlocking with a request thread. Frameworks that wrap the session lifecycle (Vaadin Flow is a documented case, vaadin/flow issue #12316) have hit this pattern.

5. If neither creation nor expiry is obviously wrong, capture a heap dump before restarting.

   # WARNING: the :live option triggers a Full GC and pauses the JVM.
   # On JDK 11+ prefer: jcmd <pid> GC.heap_dump /path/to/heap.hprof
   jmap -dump:live,format=b,file=heap.hprof $(pgrep -f 'catalina.startup.Bootstrap')
   

   Inspect with Eclipse MAT. Look for retained StandardSession instances and what holds them. The leak is occasionally a custom HttpSessionActivationListener or a static collection caching session references.

6. Do not restart as the first move. A restart clears the symptom and destroys the evidence. The thread dump and heap dump are what tell you which fix to deploy.

Metrics and signals to monitor

Fixes

Application never calls invalidate()

Add explicit session.invalidate() to logout and session-abandonment paths. Verify by watching expiredSessions rise during a controlled logout test. If session-timeout is long (hours) and most sessions are abandoned rather than logged out, lower the timeout to match actual user dwell time.

Tradeoff: lowering session-timeout shortens the idle window before users are forced to log in again. Coordinate with product.

Crawler or bot session minting

Install CrawlerSessionManagerValve in server.xml or context.xml. It identifies crawler user-agents and binds all their requests to a single session per client, collapsing the per-request session explosion (example: <Valve className="org.apache.catalina.valves.CrawlerSessionManagerValve" crawlerUserAgents=".*[bB]ot.*" sessionInactiveInterval="60" />).

Alternatively, mark crawler-facing pages with <%@ page session="false" %> so they do not mint a session at all. For endpoints that genuinely need no session (health checks, static content), ensure they do not call getSession(true).

HttpSessionListener deadlock

This requires code or framework changes. If the deadlock is in a framework, upgrade past the affected version. If the deadlock is in application listener code, remove the blocking work from sessionDestroyed: do it asynchronously, or before invalidation.

Tradeoff: moving work out of sessionDestroyed means it no longer runs under the session’s transactional context. Refactor accordingly.

Implicit JSP session creation

Audit JSPs and add <%@ page session="false" %> to any page that does not read or write session state. This is cheap and prevents the most common content-page leak.

Configure maxActiveSessions as a backstop

Set <Manager maxActiveSessions="..." /> in context.xml to a value sized to your heap. This does not fix the leak; it converts an OOM into user-visible errors and increments rejectedSessions, which your monitoring can alert on. Use it as a safety net, not a fix.

Prevention

• Alert on monotonic growth. The cleanest rule: slope of activeSessions is positive across three consecutive session-timeout windows. This eliminates false positives from a single traffic spike.
• Alert on expiry flatness. If expiredSessions is not moving over a window of a few minutes during which traffic is arriving, expiry is broken.
• Alert on rejectedSessions > 0. Even one rejected session means a configured limit is being hit and real users are seeing failures.
• Always set maxActiveSessions. It is the difference between slow degradation and a hard OOM. Size it from (post-GC heap headroom) / (average session size).
• Audit JSPs for session="false" as part of deployment review.
• Track framework session lifecycle bugs. For frameworks that hook session lifecycle, monitor upstream issue trackers for known deadlock or retention bugs.
• Capture heap dumps on OOM. Use -XX:+HeapDumpOnOutOfMemoryError. The session leak shows up clearly in retained StandardSession objects.

How Netdata helps

• Per-second JMX collection of activeSessions, expiredSessions, and rejectedSessions per context makes the slope visible before GC pressure starts.
• Correlate session counts with the old-gen post-GC baseline in the same time window to confirm whether sessions are the heap consumer or a coincident signal.
• Alert directly on rejectedSessions > 0 to catch when maxActiveSessions is being hit, rather than discovering it during an incident.
• Per-second resolution distinguishes “expiry is slow” from “expiry is blocked”; minute-level granularity can hide the difference.

Related guides

• Tomcat 5xx error rate: separating server failures from crawler 404s
• Tomcat accept queue overflow: acceptCount, somaxconn, and Recv-Q
• Tomcat access log setup: adding %D and %T for per-request latency
• Tomcat java.net.BindException: Address already in use: the connector never starts
• Tomcat average latency lies: why you need p95/p99 from the access log
• Tomcat classloader leak on redeploy: why the old WebappClassLoader never dies
• Tomcat connection refused: maxConnections and acceptCount both exhausted
• Tomcat accepts connections but never responds: the TCP-connect trap
• Tomcat frequent Full GC: pause time, G1, and the 5% overhead rule
• Tomcat GC death spiral: full GCs dominating and throughput collapsing
• Tomcat heap dump before restart: capturing evidence with jmap and jstack
• Tomcat heap usage: watch the post-GC baseline, not the sawtooth peak