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 ! >
