Hi Justin,
Thanks for your response. To elaborate on my use-case. I have a client server
application that uses multiple servers for horizontal scaling. The servers run
in containers within a Kubernetes environment. The client attaches to a server
and maintains that connection over time. If t
I wrote that on a completely different thread [1] related to MQTT retained
messages in a cluster. It is not related to this thread or your issue
generally.
Justin
[1] https://lists.apache.org/thread/oq41shfpv108m739km3rhs4tfj76c1zf
On Mon, Mar 27, 2023 at 1:28 PM Roy Cohen wrote:
> To quote:
To quote:
“This functionality isn't supported, and while it may be technically feasible
to implement I'm not sure how much sense it makes overall.”
On 27 Mar 2023, at 19:16, Justin Bertram wrote:
I'm not sure where I may have indicated that either one of those things
isn't supported.
In any
Not yet. I'm hoping to get to it at some point this week. I was out of the
office last week.
Justin
On Thu, Mar 23, 2023 at 4:31 AM Oliver Lins wrote:
> Hi,
>
> is there any news concerning this question?
>
> Oliver
>
> On 3/16/23 13:59, Oliver Lins wrote:
> > Hi,
> >
> > I've attached an arch
I think the fact that you're getting AMQ219014 explains most, if not all,
of the issues. The "packet 71" that is timing out here is the packet used
to send a message from the core client to the broker. As far as I can tell
this is your "lost" message although it's not really lost since you got a
cl
I'm not sure where I may have indicated that either one of those things
isn't supported.
In any case, you can do either.
Justin
On Mon, Mar 27, 2023 at 1:07 PM Roy Cohen wrote:
> Just to be clear: When you say “isn’t supported” do you mean a third
> broker or co located backups when running e
Just to be clear: When you say “isn’t supported” do you mean a third broker or
co located backups when running each broker on its own VM ?
> On 27 Mar 2023, at 19:04, Roy Cohen wrote:
>
> Will do Justin and many thanks for all the additional details which I will
> certainly bring forward inter
Will do Justin and many thanks for all the additional details which I will
certainly bring forward internally, much appreciated
On 27 Mar 2023, at 18:58, Justin Bertram wrote:
I recently added a new section to the clustering documentation regarding
things to keep in mind regarding performance
I recently added a new section to the clustering documentation regarding
things to keep in mind regarding performance [1].
Also, it's worth noting that often the bottleneck in messaging is not the
broker itself but rather the consumer(s). It might be worth ensuring that
the bottleneck really is th
This functionality isn't supported, and while it may be technically
feasible to implement I'm not sure how much sense it makes overall.
The whole point of clustering multiple brokers together is to increase
overall message throughput via horizontal scaling. This implies increasing
concurrency. How
I haven’t tried he group-name yet.
With regards to the third broker: The architects believe it’ll improve
performance given the amount of messages the brokers need to process (in other
words “throw more resources at it…”)
> On 27 Mar 2023, at 18:28, Justin Bertram wrote:
>
>> What would you
> What would you suggest is to do ?
Did you try my previous suggestion already (i.e. using the "group-name"
element in the "master" or "slave" element of "colocated")?
Aside from that, do you know why you were asked to add another broker?
Depending on the reason it may not be a good solution.
J
Hi Justin
It is a good question I honestly don’t have the answer for. I inherited this
configuration and was asked to add a third broker and to ensure the co located
backups are being done in such a way that each broker points on another.
Perhaps those who asked for it don’t fully understand Ar
Your screenshot didn't come through the list.
In any case, I'm pretty confused at this point. You're clearly using a
colocated configuration that will request a backup from another broker in
the cluster, but you say you're not running multiple brokers in the same
JVM. If you aren't running multipl
I don’t believe we are.
So assume three Virtual Machines on Azure.
Each VM runs one Artemis broker
[cid:2B4DF021-281F-4CFB-B5B5-E94DA3967299]
All of their ha policy section on all three brokers look like that:
1
true
1000
The main thing to understand here is that broker management is based on JMX
MBeans. MBeans are available to manage essentially all of the broker's
resources (e.g. addresses, queues, bridges, acceptors, cluster-connections,
the broker itself, etc.). As required by JMX, each MBean has a unique name,
> We are not running multiple brokers on the same JVM but a single instance
per VM, so each one has a dedicated JVM and VM
Based on your previous message I was under the impression you were using
the "colocated" feature. *If* you're using this then you definitely are
running multiple brokers in th
Hi Justin
Thank you for your input.
Sorry, should have been clearer on our setup - We are not running multiple
brokers on the same JVM but a single instance per VM, so each one has a
dedicated JVM and VM
Thanks
Roy
> On 27 Mar 2023, at 16:59, Justin Bertram wrote:
>
> I'm not entirely sure
I'm not entirely sure if the configuration you want is possible. You might
try using the "group-name" element in the "master" or "slave" element of
"colocated." Only servers with the same group-name will pair together.
Aside from that I would actually recommend against using colocated brokers.
The
1. Why change ?
2. What would the co located back strategy look like with three ? Will it align
to my expectation below ?
Broker01 -> Broker02
Broker02 -> Broker03
Broker03 -> Broker01
3. How can I prove the co located backup strategy with three brokers ?
> On 27 Mar 2023, at 16:05, prateekja
IMO, the only change would be changing broker (61616 to something like
61618) port. I would expect everything should work after that.
Regards,
Prateek Jain
--
EXPECTATION : Causes all troubles..
--
Hi Prateek
Thanks, however that example is for two brokers, which we already have working.
We are now adding a third broker to the cluster and want to understand how to
change the co located backups according to my original post.
Is that possible ?
Regards
Roy
> On 27 Mar 2023, at 15:46, p
It's not clear to me what is not actually straightforward about managing a
text configuration file.
In any case, just about every platform and architecture has a way to manage
configuration files. Helm charts are a good example. One of the goals with
keeping the "create" command simple is so that
Hi Roy,
I dont exactly know your usecase or constraints but IMO, shared store
would have been a better option. As I didnt worked/explored 1.x version so,
wont comment on it. But you should be able to reference examples under
artemis directory:
*examples\features\ha\colocated-failover*
Hope i
Hi Justin,
Yes, I could have done that but I wanted to know if there are straight
forward ways of doing such things. Just for the sake of other/future users,
I found an approach of achieving this in a project on github
https://deviceinsight.github.io/activemq-artemis-helm
Although, I wont be
Anyone has any thoughts on the below ?
On 23 Mar 2023, at 12:37, Roy Cohen wrote:
Hello everyone
We have a setup of three Artemis brokers (very old version don’t ask :))
We would like to configure the co located backups such that the backups are
sent in this order:
Broker01 -> Broker02
Bro
The "create" command only supports a handful of customizable configuration
options. It is meant to be a simple tool to perform simple customizations.
For more advanced use-cases you simply need to provide your own broker.xml.
I recommend you use the "create" command to create a default broker.xml
Hi All,
My requirement is to start/create a new broker with custom settings which
are specified in the broker.xml file. These settings include things like,
1. Specifying/adding new queues and topics.
2. Specifying custom broadcast settings like jgroups settings
5000
* test
28 matches
Mail list logo
