great, it makes sense to reuse the existing distributed lock, that has been well hardened. https://github.com/apache/artemis/blob/main/artemis-lockmanager/artemis-lockmanager-api/src/main/java/org/apache/activemq/artemis/lockmanager/DistributedLockManager.java#L54
the zk tests can be reused also. along with broker connections being locked, activation of the store could also do with a leader lock. peer leader follower works well know with the existing store exclusive locks, but it would be great to be able to mix and match. jdbc leader on a broker using shared file store, where there is no support for a distributed file lock. On Mon, 26 Jan 2026 at 19:18, Clebert Suconic <[email protected]> wrote: > I will not add anything for Federation and Bridge now... > > I will do this at a later point after some more thinking about it. > > On Mon, Jan 26, 2026 at 9:04 AM Clebert Suconic > <[email protected]> wrote: > > > > I was thinking.. I will apply the same pattern to other objects beyond > > acceptor. Think of federation being activated after a message hits > > the target. > > > > > > I could of course change the Mirror target to not apply federation, > > like I did with clustering. But applying the lock to Federation > > wouldn't be a bad idea. > > > > On Wed, Jan 21, 2026 at 10:14 PM Clebert Suconic > > <[email protected]> wrote: > > > > > > On Thu, Jan 15, 2026 at 1:35 PM Christopher Shannon > > > <[email protected]> wrote: > > > > > > > > If adding support for etcd I also think that Zookeeper should be > supported > > > > as it is similar but is Apache and Java based. > > > > > > We already had CuratorDistributedLockManager encapsulating ZooKeeper.. > > > I will enhance from the implementations we had before.. so it will be > > > there. > > > > > > > > -- > > Clebert Suconic > > > > -- > Clebert Suconic > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
