[
https://issues.apache.org/jira/browse/ARTEMIS-2504?focusedWorklogId=319634&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319634
]
ASF GitHub Bot logged work on ARTEMIS-2504:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 27/Sep/19 15:59
Start Date: 27/Sep/19 15:59
Worklog Time Spent: 10m
Work Description: jbertram commented on issue #2850: ARTEMIS-2504
implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-535998932
> How does someone control if the retroactive address will behave when full,
e.g. page, block, drop?
For the most part you can control the configuration of the internal
retroactive address/queues using address settings just like any other address.
The resources are named according to a specific pattern which can be used in
the `match` for the address-setting.
> How or where can someone configure the naming of a retroactive address so
they can control their names to avoid conflict or for security settings.
The naming pattern is outlined in the documentation. Conflicts can be
avoided through the `internal-naming-prefix` setting.
> For queues created for retroactive, if there is a very high number of
message groups and someone is using buckets so that the group map doesnt
explode in size, how is this being avoided in the retroactive queue?
Configure the group buckets via an address-setting. I changed this in my
latest update.
> Is routing type being preserved.
Yes, it is being preserved now. I changed this in my latest update.
> Why divert and separate address is needed. Why not have the retro queue
under the original address?
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.
> Default address routing type in the validator for msg count?
Fixed in the my latest update.
> On the retroactive queue, would want a flag to tell us its a retro queue,
thats then exposed to jmx so that metrics systems can get the tag, and so
alerting rules on queue depths can ignore these queues automatically based on
that flag.
Added on my latest update.
> In future or even in this pr it would be good to be able to explicitly
set/control [the retroactive-message-count] at an address level. Thus this
would just be a default thats then applied if none is set at that level
As far as I can tell that is already how `retroactive-message-count` is
functioning. If not defined then the default of `0` is used. Addresses
themselves have no direct configuration attributes other than `name`. The
`address-settings` block is designed to configure the settings for an address.
I see `retroactive-message-count` the same as settings like `max-size-bytes`
and a bunch of others.
> This suggests it updates dynamically. It isnt entirely true as will only
update the default for new addresses, existing addresses where the retro queue
is created already it doesnt update.
That's not true. There is a listener which will update the `ring-size` on
the ring queues dynamically.
> This feature would be more powerful if support for a timebased or bytes
size retention, e.g. retro active for last hour etc.
Fair enough, but that's not the subject of this PR.
----------------------------------------------------------------
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: 319634)
Time Spent: 4h (was: 3h 50m)
> 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
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
