Hi Bertram,
thanks for trying to reproduce the issue as well as the explaining comments 
related to the changes.
What did you mean with step 3 („updated the wildcard config…“)? Maybe this is 
my issue?
If not, I will try to provide a minimum reproducible setup in order to track 
down the issue.

Am Fr, 31. Mai 2024, um 22:50, schrieb Justin Bertram:
> I just tested this and it works fine as far as I can tell. Here's what I
> did:
> 
> 1) created a fresh instance of ActiveMQ Artemis 2.33.0
> 2) copied your settings into broker.xml
> 3) updated the wildcard configuration to account for the '/' in the
> address settings match
> 4) started the broker
> 5) used the "artemis consumer --destination queue:///tmp/foo
> --message-count 0" command to auto-create the address & queue
> 5) used the "artemis producer" command to send messages to it
> 6) waited
> 
> After a bit this is what I saw in the log:
> 
>   2024-05-31 13:56:13,851 INFO  [org.apache.activemq.artemis.core.server]
> AMQ224112: Auto removing queue /tmp/foo with queueID=37 on address=/tmp/foo
>   2024-05-31 13:57:43,851 INFO  [org.apache.activemq.artemis.core.server]
> AMQ224113: Auto removing address /tmp/foo
> 
> The change you referenced in relation to ARTEMIS-4125 was for a very
> specific use-case involving non-durable JMS topic subscriptions. In that
> use-case the temporary resources are cleaned up by
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.TempQueueCleanerUpper
> and that was the code that was changed in the commit you referenced. In the
> normal address/queue clean-up use-case the addresses and queues are cleaned
> up by
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.AddressQueueReaper.
> The change to TempQueueCleanerUpper doesn't have any relevance here.
> 
> If you can work up some specific steps to demonstrate a real problem I'll
> investigate further. Otherwise everything seems to be working normally.
> 
> 
> Justin
> 
> On Fri, May 31, 2024 at 7:02 AM Alexander Weichart <
> alexanderweichart_mailingl...@fastmail.com> wrote:
> 
> > **Basic bug info**
> >
> > When configuring a broker to auto-delete expired addresses like this:
> >
> > ```xml
> > <!-- broker.xml ... -->
> > <address-setting match="/tmp/#">
> >   <expiry-delay>300000</expiry-delay>
> >   <auto-delete-addresses>true</auto-delete-addresses> <!-- especially this
> > -->
> >   <auto-delete-addresses-delay>30000</auto-delete-addresses-delay>
> >   <auto-delete-queues>true</auto-delete-queues>
> >   <auto-delete-created-queues>true</auto-delete-created-queues>
> >   <auto-delete-queues-delay>30000</auto-delete-queues-delay>
> >   <auto-delete-queues-message-count>-1</auto-delete-queues-message-count>
> > </address-setting>
> > <!-- broker.xml ... -->
> > ```
> >
> > Artemis
> >
> > - correctly deletes automatically created, expired, queues
> > - **but does not** delete automatically created, expired, addresses (e.g.
> > named '/tmp/abc/123')
> >   - this leads to many old, automatically created, addresses that fill up
> > the broker
> >
> > **Further bug info**
> >
> > - I use the broker as a relay for STOMP websocket messaging (spring boot).
> > - I also verified, that the addresses had queues / messages / consumers at
> > least once.
> >
> > **Affected versions**
> >
> > - any Artemis version => 2.28.0 (
> > https://activemq.apache.org/components/artemis/documentation/latest/versions.html#2-28-0
> > )
> >
> > Furthermore, I think I found the change, that causes this behavior:
> >
> > - Version: 2.28.0 (
> > https://activemq.apache.org/components/artemis/documentation/latest/versions.html#2-28-0
> > )
> > - Ticket: ARTEMIS-4125 (https://issues.apache.org/jira/browse/ARTEMIS-4125
> > )
> > - Change: When destroying a queue, the address now only gets deleted if it
> > (the address) is marked as temporary
> > - Code Change:
> > https://github.com/apache/activemq-artemis/pull/4325/files#diff-96cdf8c4ff8d61ac9690fd5bfe2baefb4207074fc2bcd8a86d9122cb2f1ee1c2R1135
> >
> > However, in the *detailed* changelog of version 2.28.0 (
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352523&projectId=12315920),
> > the change was only mentioned as 'Address can be removed inadvertently'.
> >
> > **Other notes**
> >
> > If this is indeed intended behavior, how would one go about auto deleting
> > addresses, whose queues have expired?
> 

Reply via email to