[ 
https://issues.apache.org/jira/browse/AMQ-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré resolved AMQ-7050.
---------------------------------------
    Resolution: Auto Closed

> 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)

Reply via email to