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 <jbert...@apache.org> wrote: > >> 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. > > > Justin > > On Mon, Mar 27, 2023 at 12:07 PM Roy Cohen <roy_co...@hotmail.com> wrote: > >> 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 Artemis ! :) >> >> That said, those co located backup on the existing setup with two brokers >> do work as we have been enabled to recover lost messages in the past. So >> even not optimal, technically it does work ? >> >> I can only imagine that those who initially designed it about 5 years ago >> did not use a shared storage to avoid latency. >> >> What would you suggest is to do ? >> >> On 27 Mar 2023, at 18:00, Justin Bertram <jbert...@apache.org> wrote: >> >> 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 multiple brokers in the same JVM then what are >> you using the colocated configuration for? The whole point of the colocated >> configuration is to run multiple brokers in the same JVM (i.e. a primary >> broker and also a backup broker for another primary in the cluster). >> >> >> Justin >> >> On Mon, Mar 27, 2023 at 11:42 AM Roy Cohen <roy_co...@hotmail.com> wrote: >> >>> I don’t believe we are. >>> >>> So assume three Virtual Machines on Azure. >>> >>> Each VM runs one Artemis broker >>> >>> >>> All of their ha policy section on all three brokers look like that: >>> >>> <ha-policy> >>> <replication> >>> <colocated> >>> <max-backups>1</max-backups> >>> <request-backup>true</request-backup> >>> >>> <backup-request-retry-interval>1000</backup-request-retry-interval> >>> <excludes> >>> <connector-ref>my-connector</connector-ref> >>> <connector-ref>thishostname.mydomain</connector-ref> >>> </excludes> >>> <master> >>> <check-for-live-server>true</check-for-live-server> >>> </master> >>> <slave> >>> <allow-failback>true</allow-failback> >>> <restart-backup>true</restart-backup> >>> <scale-down/> >>> </slave> >>> </colocated> >>> </replication> >>> </ha-policy> >>> >>> >>> >>> >>> On 27 Mar 2023, at 17:26, Justin Bertram <jbert...@apache.org> wrote: >>> >>> 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 the same JVM because that's precisely what >> that >>> feature does. It runs a primary and a backup broker in the *same JVM*. If >>> you aren't using a "colocated" configuration then I'm not sure what the >>> original question is about. Can you clarify? >>> >>> >>> Justin >>> >>> On Mon, Mar 27, 2023 at 11:07 AM Roy Cohen <roy_co...@hotmail.com> >> wrote: >>> >>> 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 <jbert...@apache.org> wrote: >>> >>> 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 original use-case for this functionality was very early cloud >>> infrastructure where durable, attached storage was not readily available. >>> However, since then most (if not all) cloud environments support durable >>> storage separate from the broker so that if the broker goes down a new, >>> identical broker can be spun-up relatively quickly and attached to the >>> >>> same >>> >>> storage. This provides functional high availability without the need for >>> any idle backups or replication of any kind which functionally nullifies >>> this feature. >>> >>> Additionally, it turns out that (surprise!) configuring & running >>> >>> multiple >>> >>> brokers in the same JVM is difficult and error-prone not to mention the >>> complication of dynamically coordinating the acquisition of backups in a >>> running cluster and protecting against split-brain. >>> >>> >>> Justin >>> >>> On Thu, Mar 23, 2023 at 7:37 AM Roy Cohen <roy_co...@hotmail.com> 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 >>> Broker02 -> Broker03 >>> Broker03 -> Broker01 >>> >>> >>> I was reading on co located backups here: >>> >>> >> https://activemq.apache.org/components/artemis/documentation/1.0.0/ha.html >>> >>> however not sure I fully understand how to configure the xml section to >>> achieve that. >>> >>> Shall I add excludes in each broker, i.e. >>> >>> <colocated> >>> <excludes> >>> <connector-ref>...</connector-ref> >>> </excludes> >>> >>> Any help would be appreciated. >>> >>> Many thanks in advance ! >>> >>> >>> >>> >>> >>> >>> >>
