for etcd, there's this API here: https://github.com/etcd-io/jetcd/blob/main/jetcd-core/src/main/java/io/etcd/jetcd/Lock.java
I'm just using the simple API from jetcd... I'm not sure how k8s would allow the connection. Perhaps I would need a different API for that? On Thu, Jan 15, 2026 at 1:39 PM Gary Tully <[email protected]> wrote: > > 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] > > > > -- Clebert Suconic --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
