Hi,
Thanks for all these feedbacks, this is very interesting!
When searching on the web, I can see that most of SaaS providers provide
ActiveMQ Classic (AWS, Azure, Oracle....) not because of performance but
more because of stability of the solution.
I'm not saying that Artemis is not stable but people seems to think that
as ActiveMQ Classic is more widely use, they prefer to go with it for
stability purpose.
I saw that ActiveMQ Classic is available on docker, with persistence
storage and also the network of broker feature for connecting
on-premise/cloud brokers.
https://aws.amazon.com/blogs/compute/running-activemq-in-a-hybrid-cloud-environment-with-amazon-mq/
https://blogs.oracle.com/cloud-infrastructure/post/high-availability-for-activemq-with-mysql-and-kubernetes-on-oci
Regards,
Francois
On 29/09/2022 21:47, Justin Bertram wrote:
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> 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
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.
--
--
François
