I'm just catching up on this thread and didn't read it all thoroughly, so forgive me if I missed anything.
The idea of using Virtual Topics to meet the JMS 2.0 "named subscriptions" feature sounds like a good approach. One question that raises - removal of the queue so ensure it doesn't end up abandoned while collecting messages. Perhaps it is feasible to automatically remove the queue when the named-subscription goes away? In a network-of-brokers, there will be race conditions that will make this complicated. Virtual Topics already have the same race conditions, so it's nothing new, but something to consider - especially when the use of the feature is simplified in a way that makes it easier for developers to "just use it". An example race condition: removal of the queue on one broker while adding messages to the topic, and hence the queue, on another broker. With all that said, adding support for some of the simpler JMS 2.0 features is welcome (like the simplified session creation). Good communication will be important. We all know there will be developers who see the JMS 2.0 methods and immediately assume all of JMS 2.0 is implemented. Hope this helps. Art On Thu, Jun 25, 2020 at 9:19 AM Matt Pavlovich <mattr...@gmail.com> wrote: > I think the approach is sound. I don’t see a lot of > JMS-v2.0-as-a-minumum-version > dependency in many 3rd party systems that integrate with JMS. They tend to > use the v1.1 API > method signatures anyway. IMHO throwing an UnsupportedException is a > reasonable for the > client-side JMS 2.0-specific methods for Chris’ point 1. > > As for claiming ActiveMQ 5.x as “Supports JMS 2.0"— I think using Virtual > Topics in approach #3 sounds reasonable to > consider ActiveMQ 5.x as “Supports JMS 2.0" on the server-side. Other JMS > v2.0 brokers use queues to back durable topic > subscriptions, and make the same claim (ie IBM MQ). Also, ActiveMQ 5.x > optionally uses a similar pattern with > MQTT to be backed by Virtual Topics so it would not be setting a new > precedent within ActiveMQ or the industry > in general to call it “Supports JMS 2.0” by using a queue to back the > shared topic subscription. > > -Matt Pavlovich > > > On Jun 25, 2020, at 9:06 AM, Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > > Hi, > > > > Thanks Chris for bringing this up. > > > > First, a quick update about JMS 2.0: client API compatibility is almost > > done. I tested in Karaf, Camel and standalone Java and so far so good. > > > > My first intention when I proposed the JMS 2.0 support is first on > > client side, as least to allow client to use JMS 2.0 API. > > > > About the specific features from JMS 2.0, the first step I did is to > > return OperationNotSupportedException for now. So it's mostly Chris' > > point 1. > > > > In term of roadmap, I tried to follow recommendation and feedback from > > everyone. So roughly, that's my intention/understanding: > > > > - 5.16.0: JDK 11 support at runtime > > - 5.16.x: first JMS 2.0 client side support (before 5.17.0). > > - 5.17.0: JDK 11 support at both build and runtime and improved JMS 2.0 > > support (even if not complete on broker side ;)). > > > > I'm ready to move forward on (3), but I think it's worth to create PR > > and merge what I started already. > > > > Thoughts ? > > > > Regards > > JB > > > > > > On 25/06/2020 15:10, Christopher Shannon wrote: > >> There seems to be some confusion on what the plan is for JMS 2.0 > support in > >> 5.x so I figured it was worth starting a discussion on it. > >> > >> First, targeting a complete implementation of "full" JMS 2.0 support for > >> 5.17.0 is not very realistic in my opinion. I think 5.17.0 needs to go > out > >> faster than 5.16.0 did as for one thing it is starting to get annoying > to > >> have to use JDK 8 to build it. If JMS 2.0 support is going to happen > that's > >> probably going to take a few releases along the way with increasing > >> functionality for each one and there is still a discussion that needs to > >> happen on what will actually be done and the effort level. The main > level > >> of effort is dealing with the new shared subscription semantics. > >> > >> For example, in order of increasing effort: > >> *1)* We could just add basic API compatibility with the JMS 2.0 jar but > >> don't really implement many features at all (maybe have unsupported > >> exceptions thrown if a new method is called) which i think was the goal > of > >> 5.16.1. Note that this isn't really buying much as a user can simply use > >> the JMS 2.0 jar now with 5.x and just not call the new methods (which is > >> what I personally do) > >> *2)* We could have the Java client fake it by using Virtual topics to > >> create shared subscriptions. So if a user calls off to the shared sub > api > >> call it would just subscribe to the matching queue it needed. The > downside > >> to this is it's done all client side so would only work for the Java > client > >> and not any other open wire clients and is pretty hacky. Seems better to > >> just have the user use virtual topics natively than this way. > >> *3)* Another approach could be to add full JMS 2.0 support to OpenWire > and > >> upgrade the client/server to the new version but use Composite > destinations > >> or Virtual topics on the server to provide the functionality. The idea > >> being when the server receives the new openwire commands to create a > shared > >> subscription it fakes it by leveraging the composite destination or > virtual > >> topic feature to mimic the behavior. The main functionality to add > would be > >> client side, openwire itself and the management/tracking logic on the > >> server side to map shared subscriptions to composite > destinations/virtual > >> topics. > >> *4)* We could add true native support for JMS 2.0 to the client > (openwire) > >> and server (treat shared subs/durables as their own thing in the broker > >> logic and also in the different storage options) and this would take by > far > >> the most effort to do correctly. > >> > >> In my opinion number 3 seems the most viable if JMS 2.0 support is > really > >> desired as the level of effort wouldn't be as bad compared to trying to > do > >> full native support as described by number 4. Simply leveraging > composite > >> destinations behind the scenes seems like a decent solution on the > server > >> side as we should be able to get the desired behavior and spec > compliant. > >> > >> Alright, all of that being said, while it would be kind of nice to have > JMS > >> 2.0 in 5.x to give people options, I still lean to the idea that it > would > >> be a better use of time to just work on improving the migration and > feature > >> parity of 5.x with Artemis instead of adding JMS 2.0 support as Artemis > >> already supports it. If migration is easier and if all the main 5.x > >> features people care about work in Artemis then people could just > migrate > >> to Artemis. > >> > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > >
