Hi. Are there any updates on this?
Am Mi, 5. Jun 2024, um 11:39, schrieb Alexander Weichart: > Changing the address matcher did unfortunately not work. > Therefore, I created a minimum reproducible example for the bug. > The code & description can be found here: > https://github.com/AlexW00/spring-stomp-artemis-address-bug. > > Am Mo, 3. Jun 2024, um 17:52, schrieb Justin Bertram: > > Since your address-setting match is using "/" characters (i.e. in "/tmp/#") > > you should ostensibly define the wildcard syntax [1] to use them as well, > > e.g.: > > > > <wildcard-addresses> > > <routing-enabled>true</routing-enabled> > > <delimiter>/</delimiter> > > <any-words>#</any-words> > > <single-word>*</single-word> > > </wildcard-addresses> > > > > The default wildcard syntax uses "." characters so if you wanted to use the > > default syntax your match would be ".tmp.#" instead. > > > > > > Justin > > > > [1] > > https://activemq.apache.org/components/artemis/documentation/latest/wildcard-syntax.html#customizing-the-syntax > > > > On Fri, May 31, 2024 at 4:53 PM Alexander Weichart < > > alexanderweichart_mailingl...@fastmail.com> wrote: > > > > > 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? > > > > > > > > > >
