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

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

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

ASF GitHub Bot commented on AMQ-7050:
-------------------------------------

GitHub user alechenninger opened a pull request:

    https://github.com/apache/activemq/pull/297

    AMQ-7050: Allow alternate persistence mechanism with SubQueueSelectorCacheBrokerPlugin

    More details in JIRA. Had a go at this by pulling out an interface for cache interactions and including default, File-based implementation that behaves just as before.
    
    This flexibility is designed to allow future, alternative implementations such as a JDBC-based cache (e.g. for folks using JDBC persistence).
    
    Thanks for review!

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/alechenninger/activemq AMQ-7050

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/activemq/pull/297.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #297
    
----
commit ba9090eb5d39614cc03a3359fc1f775e9351e54f
Author: Alec Henninger <al...@...>
Date:   2018-09-08T19:32:14Z

    Pull out interface for SubQueueSelectorCache persistence

commit 8150674e15c2fe7af5a5776571577aa73c5bb362
Author: Alec Henninger <al...@...>
Date:   2018-09-08T19:47:30Z

    Remove bad import; add back default-to-empty-set behavior

commit 102ff18d0fe4c9a7b54ceb2b8f7ff4263eec25e5
Author: Alec Henninger <al...@...>
Date:   2018-09-08T20:54:32Z

    Properly remove all selector on removeConsumer with single selector

commit 460ba12fb610ffa04a1be00f850de617f6205348
Author: Alec Henninger <al...@...>
Date:   2018-09-09T12:09:37Z

    Make interface easier to implement correctly

commit 83f5c72dd39a35c8df26f0c164af63f34995224e
Author: Alec Henninger <al...@...>
Date:   2018-09-09T13:09:21Z

    Only lookup selectors if debug logging enabled

commit 955e21cae13517e41c0ff59941674f6818a5dc03
Author: Alec Henninger <al...@...>
Date:   2018-09-09T13:09:28Z

    Use try-with-resources

commit 6a1357cde588eb41e1a18dfe27ec9d27d41d5c0e
Author: Alec Henninger <al...@...>
Date:   2018-09-09T13:22:04Z

    Add javadoc, make sure returned set is not mutable per interface

commit f8bacdd430913cd627bea2b6953842d996d3a283
Author: Alec Henninger <al...@...>
Date:   2018-09-09T13:26:18Z

    Javadoc PeriodicallyFlushedFileSubSelectorCache

----


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