It may also be the underlying netty-reactor instrumentation that is the real issue as the heap dump shows a lot of cached entries for reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.
Here is the instrumentation that was loaded in the environment that was experiencing the OOM:
Related to https://new-relic.atlassian.net/browse/NR-299687
Customer reported that they were getting an OOM with their service using SpringBoot and R2DBC Mysql.
It was confirmed that disabling the
r2dbc-mysql
instrumentation resolved the memory issues:This may be related to the the use of the
@NewField
annotation and a known issue with how they interact with the caffeine cache when there are many instances of the annotation.https://github.com/newrelic/newrelic-java-agent/blob/d35ffd63177c2bffac036b1be5fec9fef6f420c1/instrumentation/r2dbc-mssql/src/main/java/io/r2dbc/mssql/client/ReactorNettyClient_Instrumentation.java#L8-L16
https://github.com/newrelic/newrelic-java-agent/blob/d35ffd63177c2bffac036b1be5fec9fef6f420c1/instrumentation/r2dbc-mysql/src/main/java/dev/miku/r2dbc/mysql/client/ReactorNettyClient_Instrumentation.java#L10-L18
It may also be the underlying
netty-reactor
instrumentation that is the real issue as the heap dump shows a lot of cached entries forreactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber
.Here is the instrumentation that was loaded in the environment that was experiencing the OOM: