[
https://issues.apache.org/jira/browse/ARTEMIS-5721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Nigro updated ARTEMIS-5721:
-------------------------------------
Description:
This is a clone of [https://github.com/quarkusio/quarkus/issues/50538] which
seems related to not properly release the ClientLargeMessageImpl's heap Netty
ByteBuf referenced into the buffer field, once not used anymore.
In short: if heap-based buffers are not released, their pool's metric will
report them as used, causing all the observability tools to think that's a leak
- even if the pool is "unpooled".
There are 2 solutions to this problem:
# release it, but the reset limit unreleaseable duplicate need to NOT be used
anymore, after it happens
# not release it but just implement (similar to what Vertx has done) a byte[]
backed ByteBuf which doesn't care about reference counting (and updating
metrics), see
[https://github.com/eclipse-vertx/vert.x/blob/master/vertx-core/src/main/java/io/vertx/core/impl/buffer/VertxByteBufAllocator.java#L47]
The test to verify if this is fixed is to capture the used heap memory from the
Netty unpooled (singleton) allocator before/after allocating such artemis
messages and don't observe any increment in such metric (see
[https://github.com/quarkusio/quarkus/issues/50538#issuecomment-3432261592),]
even after properly releasing (if required) the artemis message.
was:
This is a clone of [https://github.com/quarkusio/quarkus/issues/50538] which
seems related to not properly release the ClientLargeMessageImpl's heap Netty
ByteBuf referenced into the buffer field, once not used anymore.
In short: if heap-based buffers are not released, their pool's metric will
report them as used, causing all the observability tools to think that's a leak
- even if the pool is "unpooled".
There are 2 solutions to this problem:
# release it, but the reset limit unreleaseable duplicate need to NOT be used
anymore, after it happens
# not release it but just implement (similar to what Vertx has done) a byte[]
backed ByteBuf which doesn't care about reference counting (and updating
metrics), see
[https://github.com/eclipse-vertx/vert.x/blob/master/vertx-core/src/main/java/io/vertx/core/impl/buffer/VertxByteBufAllocator.java#L47]
> Netty unpooled heap metric keep on growing
> ------------------------------------------
>
> Key: ARTEMIS-5721
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5721
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Reporter: Francesco Nigro
> Priority: Major
>
> This is a clone of [https://github.com/quarkusio/quarkus/issues/50538] which
> seems related to not properly release the ClientLargeMessageImpl's heap Netty
> ByteBuf referenced into the buffer field, once not used anymore.
> In short: if heap-based buffers are not released, their pool's metric will
> report them as used, causing all the observability tools to think that's a
> leak - even if the pool is "unpooled".
> There are 2 solutions to this problem:
> # release it, but the reset limit unreleaseable duplicate need to NOT be
> used anymore, after it happens
> # not release it but just implement (similar to what Vertx has done) a
> byte[] backed ByteBuf which doesn't care about reference counting (and
> updating metrics), see
> [https://github.com/eclipse-vertx/vert.x/blob/master/vertx-core/src/main/java/io/vertx/core/impl/buffer/VertxByteBufAllocator.java#L47]
>
> The test to verify if this is fixed is to capture the used heap memory from
> the Netty unpooled (singleton) allocator before/after allocating such artemis
> messages and don't observe any increment in such metric (see
> [https://github.com/quarkusio/quarkus/issues/50538#issuecomment-3432261592),]
> even after properly releasing (if required) the artemis message.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
