Thank you sir :) On 28 Mar 2023, at 16:55, Justin Bertram <jbert...@apache.org> wrote:
Invitation sent. Justin On Tue, Mar 28, 2023 at 10:45 AM Roy Cohen <roy_co...@hotmail.com> wrote: > 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 ! >
