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:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to