Classification: Public Justin,
> You can use the destroyDivert management operation which takes the name of > the divert. I realize I only looked at the address level to find such management operation. And to (falsely) confirm that, I looked in the source-code for deleteDivert (similar to deleteQueue and deleteAddress) and did not find that one :-) Thx! > If you want the broker to remove diverts automatically please open a new > feature request Jira. At this moment we don’t expect to use more than a handful of retro-active addresses and we have no other uses for diverts now. destroyDivert should be sufficient for now. This may change when we get more operational experience with it. Then I might add such feature request. Thx for the suggestion! > Can you confirm that you can't delete an address when it has no queues and it > is the "forwarding-address" target of a divert? I just tested this and I was > able to delete such an address. Actually, I cannot repeat it. I'm using a cluster and probably did not delete every remote queue when I tried it and then lazily blamed the divert for it. Erwin -----Original Message----- From: Justin Bertram <jbert...@apache.org> Sent: Friday, October 27, 2023 7:01 PM To: users@activemq.apache.org Subject: Re: (auto)remove objects for retro-active EXTERNAL SENDER: Do not click any links or open any attachments unless you trust the sender and know the content is safe. EXPÉDITEUR EXTERNE: Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe à moins qu’ils ne proviennent d’un expéditeur fiable, ou que vous ayez l'assurance que le contenu provient d'une source sûre. You can use the destroyDivert management operation which takes the name of the divert. If you want the broker to remove diverts automatically please open a new feature request Jira. Justin On Fri, Oct 27, 2023 at 10:43 AM Dondorp, Erwin <erwin.dond...@ns.nl.invalid> wrote: > Non-Business > > Hello, > > For any "retro-active" address in Artemis (see > https://urldefense.com/v3/__https://activemq.apache.org/components/art > emis/documentation/latest/retroactive-addresses.html__;!!AaIhyw!qEWP3ubT3IcaPvFWC0Q_Rto8TFA5mFAe7j9WtRE-wn7FrC4eI1NYLbtA-k6GGPgMP5KTL5kIriYqmmEY69I$ > ) a few objects are created beyond what happens for a regular address: > > 1. A divert on the original address; and > 2. A related internal address ($.something); and > 3. A queue on the related internal address for anycast; and > 4. A queue on the related internal address for multicast. > > We use auto-create for all our objects. But it is hard to get rid of > these objects once they are no longer needed. The original address > cannot be not deleted due to the presence of the divert. And the > related internal address cannot be deleted due to the presence of the > divert to it. The 2 internal queues can be deleted manually though. > > Does anyone have tips or tricks to completely clean-up obsolete > retro-active addresses, without server downtime? > > thx! > Erwin > > ________________________________ > > Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor > (gebruik door) de geadresseerde. De e-mail kan persoonlijke of > vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging, > verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en > eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. > Indien u niet de bedoelde geadresseerde bent, wordt u vriendelijk > verzocht degene die de e-mail verzond hiervan direct op de hoogte te > brengen en de e-mail (en eventuele bijlagen) te vernietigen. > > Informatie > vennootschap<https://urldefense.com/v3/__http://www.ns.nl/emaildisclaimer__;!!AaIhyw!qEWP3ubT3IcaPvFWC0Q_Rto8TFA5mFAe7j9WtRE-wn7FrC4eI1NYLbtA-k6GGPgMP5KTL5kIriYqUVL5LXA$ > > >
