To satisfy our specific logic we have our own address deletion plugin.
In any case we have the section [1] you mentioned correctly set in our 
broker.xml.

I try to explain myself in another way.
We saw a possible memory leak in our tests, so we created 2 test cases to try 
to reproduce this issue.
In the first one our plugin doesn’t delete addresses (logic tells the addresses 
are not to be deleted). The broker heap memory remains more or less constant.
In the second scenario there are a lot of random addresses that are deleted by 
our plugin. In this scenario the broker heap memory grows constantly, and the 
broker goes Out Of Memory. I added a task that periodically prints the memory 
reported by the jvm but we also use the Artemis core metrics to verify the 
memory growth.

I was investigating available methods to delete addresses, and I found 4 
different way that look to me similar.
Have no idea about which is the difference, I was looking for documentation, 
but I didn’t find it.

server.removeAddressInfo(simpleAddress, null, true);
server.getActiveMQServerControl().deleteAddress(address, true);
server.getManagementService().unregisterAddress(simpleAddress);
server.getPostOffice().removeAddressInfo(simpleAddress, true);


I played with these methods, and I found a call sequence order that throws 
exception (something like not existing address exception). So I’m wonder if our 
delete is calling the wrong method.

Riccardo



From: Justin Bertram <[email protected]>
Date: Wednesday, 10 September 2025 at 16:49
To: [email protected] <[email protected]>
Subject: Re: How to programmatically delete addresses in Artemis
If an MQTT client sends messages to an address and that address never has
any queue created on it then it will not be automatically deleted by
default since the broker will not consider that address to be "used." That
may be what is happening in your MQTT "case A." If so, check out
the auto-delete-addresses-skip-usage-check [1] address setting.

I'm not sure what you mean by "no memory eating" and "memory eating" in
this context. Every AddressInfo object consumes memory simply due to its
existence.

As far as I can tell, you're deleting the address in the proper way.
However, you said that it, "...looks like there are addresses related
objects not removed from the broker memory..." and it's not clear what
those "related objects" are. Can you elaborate on this?


Justin

[1]
https://activemq.apache.org/components/artemis/documentation/latest/address-settings.html#address-settings

On Wed, Sep 10, 2025 at 2:37 AM Modanese, Riccardo
<[email protected]> wrote:

> Hi Justin,
> it’ just a thought from my findings.
> Same system setup.
> Case A) MQTT clients publishing on topics that create addresses that are
> not deleted => no memory eating on broker side
> Case B) MQTT clients publishing on different topics (every message is
> published on a new different topic). These addresses are deleted => memory
> eating on broker side
> From my checks the address looks to be deleted correctly (Artemis core
> metrics reports a constant address count).
>
> So I’m wonder if I’m doing address deletion in the right way or I’m
> forgetting something.
>
> Thanks for your support,
> Riccardo
>
> From: Justin Bertram <[email protected]>
> Date: Tuesday, 9 September 2025 at 18:39
> To: [email protected] <[email protected]>
> Subject: Re: How to programmatically delete addresses in Artemis
> Can you elaborate on the "related objects" here? What exactly isn't being
> removed?
>
>
> Justin
>
> On Tue, Sep 9, 2025 at 11:17 AM Modanese, Riccardo
> <[email protected]> wrote:
>
> > Hi guys, I have to delete programmatically addresses based on some logic
> > in Artemis broker.
> >
> > I tried with
> > SimpleString address = new SimpleString(someStringAddress);
> > ...
> > ActiveMQServer server = <current_instance>;
> > ...
> > server.removeAddressInfo(simpleAddress, null, true);
> >
> > but looks like there are addresses related objects not removed from the
> > broker memory (there is a memory leak)
> >
> > Thanks in advance for your support.
> >
> > Regards,
> > Riccardo Modanese
> >
>

Reply via email to