[
https://issues.apache.org/jira/browse/AMQ-7050?focusedWorklogId=886146&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-886146
]
ASF GitHub Bot logged work on AMQ-7050:
---------------------------------------
Author: ASF GitHub Bot
Created on: 19/Oct/23 14:05
Start Date: 19/Oct/23 14:05
Worklog Time Spent: 10m
Work Description: jbonofre closed pull request #297: AMQ-7050: Allow
alternate persistence mechanism with SubQueueSelectorCacheBrokerPlugin
URL: https://github.com/apache/activemq/pull/297
Issue Time Tracking
-------------------
Worklog Id: (was: 886146)
Time Spent: 2h 20m (was: 2h 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: 2h 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.20.10#820010)
