I used the instructions which you outlined to reproduce the issue, but from
what I could tell the proper configuration was not applied to the broker.
The address wasn't deleted, but that's because it was using the _default_
configuration where auto-delete was disabled. I set up my own local
instance of 2.34.0 and changed one line of the config:

    <auto-delete-addresses>true</auto-delete-addresses>

Then I followed your instructions to reproduce the issue, and I saw this in
the broker log:

    INFO  [org.apache.activemq.artemis.core.server] AMQ224113: Auto
removing address /topic/greetings

So ultimately everything worked as expected.


Justin

On Thu, Jun 13, 2024 at 8:27 AM Alexander Weichart <
alexanderweichart_mailingl...@fastmail.com> wrote:

> 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?
> > > > >
> > > >
> > >
> >
>

Reply via email to