[
https://issues.apache.org/jira/browse/AMQ-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16623383#comment-16623383
]
Christopher L. Shannon commented on AMQ-7050:
---------------------------------------------
I haven't looked at this too closely yet but the main thing I noticed is I
think it might make sense to make this into a new plugin. Instead of changing
the existing broker plugin maybe it should extend the current one that way
people who are happy with the existing behavior won't have any changes. (even
though the default should behave as before). Also it's easier to review if you
squash all of your commits into one commit.
> 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
>
> (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
(v7.6.3#76005)
