Gotcha. Suppose that mail group, so I hereby requesting an invite please :)
On 28 Mar 2023, at 16:40, Justin Bertram <jbert...@apache.org> 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 want an invitation to the ActiveMQ Slack channel simply send a request to the users mailing list. Most of the folks in there don't have an @apache.org email. Justin [1] https://activemq.apache.org/contact On Tue, Mar 28, 2023 at 10:31 AM Roy Cohen <roy_co...@hotmail.com> wrote: > 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 <jbert...@apache.org> wrote: >> 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 Cohen <roy_co...@hotmail.com> wrote: >>> 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 <roy_co...@hotmail.com> wrote: >>>> You have indeed ! :) >>>> On 27 Mar 2023, at 19:35, Justin Bertram <jbert...@apache.org> 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/oq41shfpv108m739km3rhs4tfj76c1zf >>>> On Mon, Mar 27, 2023 at 1:28 PM Roy Cohen <roy_co...@hotmail.com> > wrote: >>>>> 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 <jbert...@apache.org> wrote: >>>>> 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 <roy_co...@hotmail.com> >>> wrote: >>>>>> 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 <roy_co...@hotmail.com> wrote: >>>>>>> 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 <jbert...@apache.org> > wrote: >>>>>>> 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 the broker. As noted in the new > documentation >>>>>> [1], >>>>>>> adding brokers to a cluster can actually *reduce* throughput in >>> certain >>>>>>> circumstances. >>>>>>> Let me know if using group-name works for you. >>>>>>> Justin >>>>>>> [1] > https://github.com/apache/activemq-artemis/blob/main/docs/user-manual/en/clusters.md#performance-considerations >>>>>>> On Mon, Mar 27, 2023 at 12:44 PM Roy Cohen <roy_co...@hotmail.com> >>>>>> wrote: >>>>>>>> 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 !
