[
https://issues.apache.org/jira/browse/AMQ-7050?focusedWorklogId=573217&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-573217
]
ASF GitHub Bot logged work on AMQ-7050:
---------------------------------------
Author: ASF GitHub Bot
Created on: 28/Mar/21 15:43
Start Date: 28/Mar/21 15:43
Worklog Time Spent: 10m
Work Description: alechenninger commented on a change in pull request
#297:
URL: https://github.com/apache/activemq/pull/297#discussion_r602894693
##########
File path:
activemq-broker/src/main/java/org/apache/activemq/plugin/SubQueueSelectorCacheBroker.java
##########
@@ -58,39 +49,27 @@
* https://issues.apache.org/activemq/browse/AMQ-3004
*
http://mail-archives.apache.org/mod_mbox/activemq-users/201011.mbox/%[email protected]%3E
*/
-public class SubQueueSelectorCacheBroker extends BrokerFilter implements
Runnable {
+public class SubQueueSelectorCacheBroker extends BrokerFilter {
private static final Logger LOG =
LoggerFactory.getLogger(SubQueueSelectorCacheBroker.class);
public static final String MATCH_EVERYTHING = "TRUE";
/**
* The subscription's selector cache. We cache compiled expressions keyed
* by the target destination.
*/
- private ConcurrentMap<String, Set<String>> subSelectorCache = new
ConcurrentHashMap<String, Set<String>>();
+ private final SubSelectorCache subSelectorCache;
- private final File persistFile;
private boolean singleSelectorPerDestination = false;
private boolean ignoreWildcardSelectors = false;
private ObjectName objectName;
- private boolean running = true;
- private final Thread persistThread;
- private long persistInterval = MAX_PERSIST_INTERVAL;
- public static final long MAX_PERSIST_INTERVAL = 600000;
- private static final String SELECTOR_CACHE_PERSIST_THREAD_NAME =
"SelectorCachePersistThread";
-
/**
* Constructor
*/
- public SubQueueSelectorCacheBroker(Broker next, final File persistFile) {
+ public SubQueueSelectorCacheBroker(Broker next, final SubSelectorCache
subSelectorCache) {
Review comment:
I can do that if you'd like, but I lean towards this approach for the
usual composition-over-inheritance reasons.
I'm interested in better understanding how this breaks previous users or
changes the default behavior? The behavior is the same I believe, just factored
out to a separate class.
If you're concerned about changing the constructor signature, I could add
the original signature back and keep the new one.
--
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: 573217)
Time Spent: 1h 10m (was: 1h)
> 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: 1h 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)
