Thank you sir :)
On 28 Mar 2023, at 16:55, Justin Bertram wrote:
Invitation sent.
Justin
On Tue, Mar 28, 2023 at 10:45 AM Roy Cohen wrote:
> Gotcha.
>
> Suppose that mail group, so I hereby requesting an invite please :)
>
> On 28 Mar 2023, at 16:40, Justin Bertram wrote:
>
> You don'
Invitation sent.
Justin
On Tue, Mar 28, 2023 at 10:45 AM Roy Cohen wrote:
> Gotcha.
>
> Suppose that mail group, so I hereby requesting an invite please :)
>
> On 28 Mar 2023, at 16:40, Justin Bertram wrote:
>
> You don't need an @apache.org email in order to join the ASF Slack. You
> just n
Gotcha.
Suppose that mail group, so I hereby requesting an invite please :)
On 28 Mar 2023, at 16:40, Justin Bertram wrote:
You don't need an @apache.org email in order to join the ASF Slack. You
just need to request an invitation. This is noted on the website [1] (at
the bottom):
If you w
You don't need an @apache.org email in order to join the ASF Slack. You
just need to request an invitation. This is noted on the website [1] (at
the bottom):
If you want an invitation to the ActiveMQ Slack channel simply send a
request to the users mailing list.
Most of the folks in there don
Understood and yes there’s a reason.
Don’t I need @apache.org email in order to join that Slack workspace ?
> On 28 Mar 2023, at 15:52, Justin Bertram wrote:
>
> Typically we like to keep everything on the list so the whole community can
> benefit from the discussion. However, if there's a spe
Typically we like to keep everything on the list so the whole community can
benefit from the discussion. However, if there's a specific reason that
privacy is a concern then you can email me directly or you can find me on
the ASF Slack in #activemq.
Justin
On Tue, Mar 28, 2023 at 7:56 AM Roy Coh
Hi Justin
Would it be able to reach out to you directly to discuss a couple of points
around the discussion below privately ?
Thanks
Roy
> On 28 Mar 2023, at 10:26, Roy Cohen wrote:
>
> You have indeed ! :)
>
> On 27 Mar 2023, at 19:35, Justin Bertram wrote:
>
> I wrote that on a complet
You have indeed ! :)
On 27 Mar 2023, at 19:35, Justin Bertram wrote:
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/oq41shfpv108m739km3rhs4t
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
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
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
> 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
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
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
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
Broker02 -> Broker03
Broker03 -> Broker01
I was reading on co located backups here:
ht
28 matches
Mail list logo
