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 b
Hi Endre,
It should work with 6.0.0 (as we have both javax and jakarta namespace
and JMS API is backward compatible). But it's mostly a transition
purpose.
So, maybe I wasn't clear: it should work, but I would recommend to
upgrade to clients too at some point :)
Regards
JB
On Mon, Mar 18, 2024 a
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 b
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 wrote:
>
> Hi!
> Thanks for the release!
>
> I have a question wrt. upgrading a 50+ microservice solution: How is the
> compatibility betw
Hi Endre-
Technically speaking, this current release set covers that last known
compatibility issue where typed exceptions where being downcast to simple
JMSException when doing a javax <-> jakarta conversion. For example, a
ResourceAllocationException (for producer flow control) would come acr
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. su
