Endre:
I will note, due to performance issues we have been unable to identify
with Active MQ 5.16.x + (upgrading from 5.15.16) we are experimenting
with ActiveMQ Artemis and so far have not run into any compatibility
issues. I appreciate your concerns with moving from one broker to
another but they might be unfounded. We are only using the openwire
protocol, setup is fairly simple however it is a high volume
transactional system.
Thanks!
Steve.
On 3/18/24 7:59 AM, Endre Stølsvik wrote:
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é <[email protected]>
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 <[email protected]>
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é <[email protected]>
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
