Memory leak on javaagent 1.5.1

[lmssy]

Here is an OOM dump below:

javaagent version: 1.5.1
params: -Dotel.metrics.exporter=none -Dotel.exporter.otlp.traces.endpoint=http://myip:4317 -Dotel.traces.sampler=parentbased_traceidratio -Dotel.traces.sampler.arg=1 -Dio.opentelemetry.context.enableStrictContext=true

I have applications run on 1.3.1 and 1.4.1 for a long time without OOM, yeaterday I upgrade to 1.5.1 and my application crashed by OOM.

Please have a look, thanks.

[anuraaga]

@lmssy I don't know if it will have better or worse performance, but can you try -Dotel.metrics.exporter=logging (or just leave it at default and accept that metric export requests are attempted but fail)?

@jsuereth @jkwatson I have a feeling we have an issue with the metrics SDK storage that it can grow forever if no exporter is configured to trigger resets.

[jkwatson]

@jsuereth are we keeping points around rather than summing them up in the buckets?

[jkwatson]

Now I'm confused. We only generate these during a data collection, which only happens if an exporter is configured. So, I don't understand how these are being kept around by anything, unless there's some exporter that is holding on to them indefinitely and not actually exporting them.

[jkwatson]

and, yes, there is an IntervalMetricReader wired up here, I see that above.

[jkwatson]

@lmssy how long are you waiting before grabbing the heap? The IntervalMetricReader has a default interval of 1 minute, so you would only see these getting swept out and GC'd on a minute interval, unless you explicitly configure a shorter time interval with the otel.imr.export.interval setting.

[jkwatson]

Also, now that 1.5.2 has been released, can you check this again, removing the logging exporter configuration altogether?