I was kinda hoping that there was some solution here, because otherwise it will be a rather big bang to get over to 6.
I was hoping that I could upgrade the broker to 6, and then roll out upgrades to the heap of services (the client side) over the next few months. I can envision that this won't be an uncommon situation: A big part of the idea with a MQ broker is that you have one of them, and then multiple clients connecting to it. Requiring all of the clients to go from 5 to 6 at the same time is close to an insurmountable task, and very much not what one want for such a microservice architecture, where at least we try to do everything in a fashion where each of the sub-projects (the microservices) can handle their upgrade when it best suits them. Since this is a wire protocol that is close to totally disjunct from the APIs used on each side, such a "guarantee" (for a period) should not be impossible to make? Maybe make a final 5.x release/client that incorporates the necessary changes for 6.x, and then keep it in mind when changing the wire protocol on the v.6 server side? For a while? Thanks a bunch, Endre. On Mon, Mar 18, 2024 at 6:26 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi, > > If you are still using ActiveMQ 5.x clients, I recommend staying with > an ActiveMQ 5.x broker. > > Regards > JB > > On Sun, Mar 17, 2024 at 11:58 AM Endre Stølsvik <en...@stolsvik.com> > wrote: > > > > Hi! > > Thanks for the release! > > > > I have a question wrt. upgrading a 50+ microservice solution: How is the > > compatibility between old JMS clients (5.x) towards the 6+ server > versions? > > > > I guess the wire protocol doesn't care one bit wrt. javax./jakarta? But > do > > the ActiveMQ team have any suggestion wrt. such an upgrade situation? Are > > there any "guarantees" wrt. the future compatibility between client > > versions and server versions? > > > > I ask since any such compatibility guarantee would put my mind a bit more > > at ease wrt. doing the upgrade in a rolling fashion. We do obviously > have a > > test env, but knowing whether there is any intention, or not, wrt. > > compatibility, would be of value. > > > > The problem is of course that the jakarta-situation is a bit .. large. > Both > > the JMS libs, the Servlet libs, and Spring, pretty much have to be done > "in > > one go". So knowing what works with what is of value in setting up a > > transition path. > > > > Thanks, > > Endre > > > > > > > > On Sun, Mar 17, 2024 at 11:38 AM Jean-Baptiste Onofré <j...@nanthrax.net> > > wrote: > > > > > The ActiveMQ team is pleased to announce Apache ActiveMQ 6.1.0 release. > > > > > > It's a new milestone, bringing: > > > - New JMS 2/3 operations support > > > - Mapping javax / jakarta exception in openwire protocol > > > - Add destination field on the job scheduler > > > - Add org.apache.activemq.broker.BouncyCastleNotAdded property to > > > control the bouncycastle addition in BrokerService classloader > > > - A lot of dependency upgrades (Spring 6.1.4, log4j 2.23.0, Jetty > 11.0.20, > > > …) > > > - ... and much more ! > > > > > > You can find details on the Release Notes: > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353745 > > > > > > You can download ActiveMQ 6.1.0 here: > > > https://activemq.apache.org/components/classic/download/ > > > > > > Enjoy! > > > > > > Regards > > > -- > > > The Apache ActiveMQ team > > > >
