[
https://issues.apache.org/jira/browse/AMQ-7050?focusedWorklogId=562243&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-562243
]
ASF GitHub Bot logged work on AMQ-7050:
---------------------------------------
Author: ASF GitHub Bot
Created on: 08/Mar/21 09:07
Start Date: 08/Mar/21 09:07
Worklog Time Spent: 10m
Work Description: lucastetreault removed a comment on pull request #297:
URL: https://github.com/apache/activemq/pull/297#issuecomment-792580314
Can one of the admins verify this patch?
----------------------------------------------------------------
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: 562243)
Time Spent: 20m (was: 10m)
> Allow alternate persistence mechanism with SubQueueSelectorCacheBrokerPlugin
> ----------------------------------------------------------------------------
>
> Key: AMQ-7050
> URL: https://issues.apache.org/jira/browse/AMQ-7050
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
> Affects Versions: 5.15.6
> Reporter: Alec Henninger
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> (Largely copied from my email to dev list)
> Background: We're running a multitenant activemq pair using selector aware
> virtual topics extensively but also need truly durable subscriptions. The
> SubQueueSelectorCacheBroker plugin was developed for this purpose as we
> understand, however it persists the selector cache in a File, and we'd like
> to instead use a shared/replicated cache that doesn't depend on a node first
> storing the cached consumer selector locally first. The reason for this is,
> with the current implementation, there is an edge case where if both:
> 1. A active broker has not yet cached a consumer's selector (e.g. secondary
> broker becomes primary that hasn't yet received connection from said consumer
> and brokers are not sharing networked file system)
> 2. Producer connects and starts publishing messages before consumer
> ...then those messages will be lost. In some domains, any message loss is
> really undesirable so we want to do everything we can to prevent that while
> still using selector aware virtual topics. We'd just turn off selectorAware,
> but then we have to deal with message build up for consumers using selectors,
> and we have little control over how/when consumers use selectors.
> Hence, refactoring SubQueueSelectorCacheBroker to allow an alternate source
> of persistence enables us to experiment with a fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
