michaelpearce-gain edited a comment on issue #2850: ARTEMIS-2504 implement retroactive addresses URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-536613138 @jbertram re: "My original plan was to have the ring queues for the retroactive address under the main address itself, but I didn't want those queues to be subject to the address-settings of that address. Separating the ring queues onto their own address means better configuration flexibility." The issue here are 1) you have to message copy, not just make new references - expensive if you have a large retro active to get through, also will cause paging faults to occur as copies occur, even if consumer isnt at that message. 2) its going to be very messy as an end user to make address settings for the internal's, especially as typically (as an end user, i probably just want the same settings for bit like paging etc) 3) address settings do not update the queue (in general they are defaults, overrides and actuals are always set at queue level), as such once queue is created its not going to be possible to adjust Also having it at the address allows us to, and the way i was seing this working so then you can set this being better configurable and working nicely is to have these defined as sepecial queues under the address (eg. in broker.xml) <address name="MyAddress"> <multicast> <queue name="MyQueue" group-buckets="64" group-rebalance="true"> <filter string="ServiceId = 1" /> <durable>true</durable> </queue> <retro-active-queue group-buckets="0" message-count="1024" /> </multicast> </address> This way then it can expose any queue settings, easily, where retro-active-queue is of same schema type as queue (so going forwards as features added, it just maintains) Also then under the address-settings, say someone wants to define a number of defaults we could structure it: <address-settings match="blah"> <default-retroactive-multicast-queue group-buckets="0" message-count="20" /> <default-retroactive-anycast-queue group-buckets="0" message-count="20" /> </address-settings> Again here this actually is of schema (xsd) queue, and basically this becomes then a queue template, meaning again as features added to queue, we dont have to maintain seperate configs ensuring they align and expose all. This all works though based on the idea the retro queue for an address is under same address. Like wise will mean say for anycast we dont want retro but mutlicast we do, there is a nice split as well.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
