A couple notes on shared durable subscriptions:
1. They are limited per the spec (you can’t mix shared and non-shared)
2. The effectively create ‘queue’ characteristics on a topic
Given the above, most users have moved to using ActiveMQ’s Virtual Topics
instead. They are much easier to manage and rationalize once you move past one
broker. (Clustering topics can get weird). The code is simpler and more
portable as well.. can consumers can just consume from queues, have ability to
browse, and all the other good features that come with using queues..
That being said, I do hope that we get an implementation for nothing else than
it checks the box.
I think there are two approaches:
1. Map topic addresses to queues for shared-durable subscriptions and use
Virtual Topics on the broker-side
2a. Update openwire, the broker and the store to fully support shared durable
subs
2b. Do a destination mapping approach where shared durable subs are mapped to
queues (like how we do in MQTT)
I think I can get #1 done pretty quickly— Q1 of next year would be reasonable
#2b seems more likely than #2a longer term.
Thanks,
Matt Pavlovich
> On Nov 16, 2023, at 8:05 AM, Christopher Shannon
> <christopher.l.shan...@gmail.com> wrote:
>
> I don't think it is very likely shared durable topics are going to be
> available in 6.1.0, unless we don't plan to release 6.1.0 for a long time.
>
> Shared subscriptions are going to be a decent amount of work to get correct
> as I don't think we should just hack the client to created a virtual topic
> as then it's entirely up to the client to manage things and there's no
> state tracking on the broker side. To do it properly the broker needs to
> handle mapping the subscriptions to queues transparently. We can leverage
> composite destinations and virtual subs but we still need to figure out how
> this is going to be mapped and tracked by the broker when a client makes a
> shared subscription request. There's issues to work out as well based on
> the spec and what is and isn't allowed. The cleanest solution would be a
> new OpenWire version with a new shared sub name.
>
> So my point is, I don't think this feature is particularly close to being
> done considering no one is actually working on it and there are likely
> probably going to be other issues that come up that require us to release
> 6.1.0 much faster than shared durables or shared subs will be ready so the
> only thing we can really say is it will be available at some point in a 6.x
> release
>
> On Thu, Nov 16, 2023 at 8:41 AM Jean-Baptiste Onofré <j...@nanthrax.net>
> wrote:
>
>> Hi,
>>
>> The first support has started in ActiveMQ 6.0.0 currently in vote.
>> However, some features are not fully implemented, it's planned for
>> 6.1/6.2 releases.
>>
>> For instance, regarding Shared Durable Topic, you can see some method
>> throwing IllegalStateException("Operation not supported by a
>> TopicSession").
>> That's the case for the methods from JMS 2.0/3.1 and not yet
>> implemented (like createSharedDurableConsumer for example).
>>
>> To be honest, I'm not a super fan of what we did here, I think it
>> would have been better to have a full running implementation. As we
>> wanted to have JMS 2.0/3.1 (and so Jakarta namespace support), we did
>> this approach in 5.18 (in the activemq-client-jakarta module) and now
>> in 6.0.0 (directly in activemq-client).
>> Now, we will implement method by method.
>>
>> To be concrete on your question, Shared Durable Topic feature will be
>> fully implemented in 6.1.0.
>>
>> Regards
>> JB
>>
>> On Thu, Nov 16, 2023 at 12:21 PM Jean-Louis Monteiro
>> <jlmonte...@tomitribe.com> wrote:
>>>
>>> Hi all,
>>>
>>> Any information or plans for the JMS 2.0 / JMS 3.1 implementation in
>>> ActiveMQ Classic?
>>> I'm more interested in the Shared Durable Topic feature.
>>>
>>> With some guidance or help, I can probably help on this.
>>>
>>> Thanks
>>> --
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>
