[jira] [Work logged] (AMQ-7050) Allow alternate persistence mechanism with SubQueueSelectorCacheBrokerPlugin

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AMQ-7050?focusedWorklogId=562202&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-562202 ]

ASF GitHub Bot logged work on AMQ-7050:
---------------------------------------

                Author: ASF GitHub Bot
            Created on: 08/Mar/21 08:38
            Start Date: 08/Mar/21 08:38
    Worklog Time Spent: 10m 
      Work Description: lucastetreault commented 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:
users@infra.apache.org


Issue Time Tracking
-------------------

            Worklog Id:     (was: 562202)
    Remaining Estimate: 0h
            Time Spent: 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: 10m
>  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)