My two concerns / requirements for me to give a non negative vote are 1) ensuring anything done works the same with Artemis, we should avoid adding any changes that cause divergence with compatibility with Artemis using openwire clients , else we risk introducing further issues for those migrating, which we’ve been clear as a community is the way forward.
2) any openwire protocol changes we ensure nms openwire is updated to avoid causing any changes that may cause issues. I don’t want this left as a problem left for others to clean up. Regards Mike Sent from my iPad > On 25 Jun 2020, at 17:20, Matt Pavlovich <[email protected]> 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é <[email protected]> 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é >> [email protected] >> http://blog.nanthrax.net >> Talend - http://www.talend.com >
