For etcd in k8s the lock would need to be on an kind supported by the API server, stored in etcd. That pattern is exposed by the java operator sdk. That can be done after.
On what can be locked? A non persistent broker could maybe use the server but a follower will need to live enough to be visible in jmx. If a shared file store broker was to use jdbc as a L/F lock, where would that lock attach? Would it make sense to have components lockable or have a broker plugin allow locks at each intercept? We can do it on a case by case basis, but maybe there is a general way? Just a few thoughts! On Thu, Jan 15, 2026, 15:50 Clebert Suconic <[email protected]> wrote: > I am working on a feature that would allow the leader/follower usage > on acceptors. > > An acceptor would be waiting for a lock, and it would start the > acceptor when the lock is acquired, and stop when the lock is lost. > > > I am working to add a few types of locks: > > - etcd > - fileShared > - JDBC > > > > I have a few questions on the implementation: > > > i - is etcd useful on the openshift world? > > it seems that the PODs will not have access to etcd directly and an > operator is supposed to prepare the lock in some indirect way. ETCD > might still be useful for standalone, but perhaps this is not a good > fit for the openshift world. > > > > > ii - netty and vertx implementation. > > I am playing https://github.com/etcd-io/jetcd, and it is bring vertx and > netty. > Currently I had to revert back one version as the netty version is > clashing with our current netty usage. What brings me to think.. is > this the right approach since it will bring vertx and netty as > external dependencies from the library. > > > > iii - Perhaps I should skip the etcd option for now and only support > fileLock and JDBC. > > iv - how to configure this. > > > I'm planning to add something like leadership in the XML > > > <leadership> > <leader lock-name="myLock" type="Type"> <!-- type being file, jdbc, > or etcd (if we are still going for it) --> > <properties> > </properties> > </leader> > </leadership> > > > and on either acceptor or server > > <server leader="myLock"> ... > > > <acceptor leader="myLock"> > > > > the idea is that one leader choice could be able to start or stop > multiple objects (in this case for now, server or acceptors).. you > could have multiple acceptors towards the same leadership ellection. > > > > any feedback is appreciated. > > > > -- > Clebert Suconic > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
