Sentry Java Memory usage on 8.x.x with SentryServletRequestListener

[aleksabl]

Integration

sentry

Java Version

21

Version

8.0.0-

Steps to Reproduce

1. In a project using SentryServletRequestListener, upgrade from 7.22.6 to 8.0.0 or 8.23.0

Expected Result

Not going OOM

Actual Result

In production, we gradually run into OOM errors when using Sentry 8.x. It consumes 1–2 GB of memory per minute, so after roughly 15 minutes we hit OOM even with a 30 GB max heap. During this time, we’ve likely only sent around 30 events. We’re not using the Sentry agent, performance monitoring, etc. — only error monitoring.

I’ve tried several versions, and the latest on the 7.x branch doesn’t have this issue. However, both 8.0.0 and 8.23.0 do.

These are the classes from production with the most instances:

Class	Count
io.sentry.Breadcrumb	15,953,361
io.sentry.util.AutoClosableReentrantLock	1,662,754
io.sentry.Scope	332,543
io.sentry.PropagationContext	332,543
io.sentry.CircularFifoQueue	332,543
io.sentry.SynchronizedQueue	332,543
io.sentry.protocol.Contexts	332,543
io.sentry.Scopes	166,271
io.sentry.protocol.User	166,271
io.sentry.CombinedScopeView	166,271
io.sentry.logger.LoggerApi	166,271
io.sentry.internal.eventprocessor.EventProcessorAndOrder	166,065
io.sentry.servlet.jakarta.SentryRequestHttpServletRequestProcessor	166,065
io.sentry.DefaultScopesStorage$DefaultScopesLifecycleToken	156,952

[linear]

JAVA-204

[aleksabl]

It looks like all the Scopes-instances are chained through parent:

[aleksabl]

I think the issue is at https://github.com/getsentry/sentry-java/blob/main/sentry-servlet/src/main/java/io/sentry/servlet/SentryServletRequestListener.java#L46:
scopes.forkedScopes => ScopesAdapter.forkedScopes => Sentry.forkedScopes => getCurrentScopes().forkedScopes and calles makeCurrent => Sentry.setCurrentScopes with the new Scopes. This ends up just creating a longer and longer chain of Scopes (parent is getCurrentScopes and the new instance is set with setCurrentScopes).

[lcian]

Hey @aleksabl, thanks a lot for the report and analysis. We'll take a look as soon as possible.

[adinauer]

@aleksabl are you using any kind of async version of servlets?

Have you by chance investigated order of requestInitialized vs. requestDestroyed and which threads they are executed on?
For multiple requests it should still be paired init + destroy and init + destroy, not init + init + destroy + destroy

Notes for us:
Do some testing on our sample.
We could try forkedRootScopes but that needs testing against OTel to see if it breaks anything.
Reduce number of request handler threads to 1 to see if we can force the problem.