One additional note regarding HA and shared storage on K8s. Check what shared
storage options are available in your K8S environment beforehand, because there
are not so many, and both Artemis and “Classic” is pretty picky about shared
storage filesystem.
For example, for us, on Google Cloud, it was either we use replication (which
is available only on Artemis), or we move our messaging to VMs with NFSv4
shared storage.
--
Vilius
From: Justin Bertram <jbert...@apache.org>
Sent: Thursday, September 29, 2022 10:47 PM
To: users@activemq.apache.org
Subject: Re: Artemis vs AMQ 5.x in production
Your use-case as stated is straightforward, and either broker could handle it
functionally no problem.
I see a potential risk regarding HA. ActiveMQ "Classic" only supports HA via a
shared store whereas Artemis supports both shared store and replication. If you
can't or simply don't want to configure shared storage or shared storage is too
slow then Artemis would be your only option. Replication can be nice as it
eliminates the shared store as a single point of failure and the brokers get
the performance benefit of using local disks.
Here's a few forward-looking potential risks:
1) Since you're basically using JMS exclusively there may be a risk if you
ever need to move to JMS 2 or Jakarta Messaging 2.0 or 3.0. Artemis already
ships clients with full support for these APIs. Given recent messages on the
mailing list I believe there are plans to implement this support for ActiveMQ
"Classic," but it may be that a bird in the hand is worth two in the bush, as
they say.
2) If your load increases substantially or your performance needs become more
aggressive (or both) then you may hit a ceiling with "Classic" where you can't
get the numbers you need.
That's all I can think of off the top of my head.
It's hard for me to comment on the K8s angle as I don't work much in that area,
but https://artemiscloud.io/ may be a helpful resource for you.
Justin
On Thu, Sep 29, 2022 at 1:16 PM John Lilley
<john.lil...@redpointglobal.com.invalid<mailto:john.lil...@redpointglobal.com.invalid>>
wrote:
Greetings,
I can see this question has been asked in some form before, and recently. But
I just wanted to clarify our use case and ask which version would be a better
bet going into production in a few months. Some details:
* Client/service access is 99% via JMS, except for a few management methods
(enumerate queues, get queue count) which we hit via Jolokia
* Usage is 95% RPC (post to named queue, reply on temp queue) and 5% topics
* AMQ has been working in test for many months. Artemis is being tested
and we are shaking out a few semantic differences.
* Our performance needs seem to be covered by both versions.
* We don’t need HA yet. HA is on the roadmap for 2023.
* We need persistence (so messages are not lost if broker is bounced)
* We are in a Kubernetes pod environment. The broker itself *can* run in a
separate VM if that is the preferred or more-stable configuration.
We realize the Artemis is the future, so we are inclined that way if possible.
In order to avoid opinion wars, I really just want to ask “what are the known
risks” for the two options. Given that we are in K8S, does one have better K8S
support/experience over the other?
Secondary question: is it OK to deploy the broker in K8S pods, or is it better
to use a dedicated VM?
Thanks
john
[rg]<https://www.redpointglobal.com/>
John Lilley
Chief Architect, Redpoint Global Inc.
888 Worcester Street, Suite 200 Wellesley, MA 02482
M: +1 7209385761<tel:+1%207209385761> |
john.lil...@redpointglobal.com<mailto:john.lil...@redpointglobal.com>
PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is confidential
and is intended solely for the use of the individual(s) to whom it is
addressed. If you believe you received this e-mail in error, please notify the
sender immediately, delete the e-mail from your computer and do not copy, print
or disclose it to anyone else. If you properly received this e-mail as a
customer, partner or vendor of Redpoint, you should maintain its contents in
confidence subject to the terms and conditions of your agreement(s) with
Redpoint.
