Years ago Artemis used to use byte-range locks, but we switched to simple file locks in the 2.10.0 release (see ARTEMIS-2441 [1]). Therefore, I don't expect the "-nobrl" flag to have any impact since we don't use byte-range locks.
Really the only thing you need in a remote file-system is something that supports exclusive file-locks. You also need to disable any client caching so that anything written to disk by the broker is actually written to the remote filesystem and not cached on the client somehow otherwise you risk losing data when the broker crashes which essentially defeats the purpose of configuring high-availability in the first place. Justin [1] https://issues.apache.org/jira/browse/ARTEMIS-2441 On Fri, Oct 4, 2024 at 3:54 PM Lino Pereira <lino.pere...@redpointglobal.com.invalid> wrote: > Hi, > > We are using Artemis-HA, with the live and backup instances, in our K8S > deployment in Azure. In our config, we have a “activemq-shared-store-pvc” > volume backed by an Azure File Share that is shared by both the live and > backup Artemis instances to keep live/backup state. > > Generally, do you have specific recommendations for the Azure Storage > Class settings that should be used for such a volume. > > More specifically, when creating a StorageClass in Azure Kubernetes for > such a volume, I encountered an advisory in Azure documentation that > recommends including the -nobrl flag in the mount Options. The > documentation states that this flag is crucial for avoiding issues related > to byte range locks in certain applications, i.e.: > # Disables sending byte range lock requests to the server and for > applications which have challenges with POSIX locks. > > What is your recommendation regarding including the -nobrl flag for the > “activemq-shared-store-pvc” volume that is shared by Artemis-HA instances > to keep live/backup state? > > Thanks, > Lino > > > [rg] <https://www.redpointglobal.com/> > > Lino Pereira > > C++ Developer, Redpoint Global Inc. > > 34 Washington Street, Suite 205 Wellesley Hills, MA 02481 > > lino.pere...@redpointglobal.com<mailto:lino.pere...@redpointglobal.com> > > PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is > confidential and is intended solely for the use of the individual(s) to > whom it is addressed. If you believe you received this e-mail in error, > please notify the sender immediately, delete the e-mail from your computer > and do not copy, print or disclose it to anyone else. If you properly > received this e-mail as a customer, partner or vendor of Redpoint, you > should maintain its contents in confidence subject to the terms and > conditions of your agreement(s) with Redpoint. >
