[
https://issues.apache.org/jira/browse/ARTEMIS-2504?focusedWorklogId=320585&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-320585
]
ASF GitHub Bot logged work on ARTEMIS-2504:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 30/Sep/19 15:43
Start Date: 30/Sep/19 15:43
Worklog Time Spent: 10m
Work Description: michaelpearce-gain commented 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]
Issue Time Tracking
-------------------
Worklog Id: (was: 320585)
Time Spent: 4h 40m (was: 4.5h)
> Support retroactive addresses
> -----------------------------
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Reporter: Justin Graham Bertram
> Assignee: Justin Graham Bertram
> Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
