@Gary: what I probably need is the kubernetes API to access the lock? either fabric8 or io.kubernetes?
On Thu, Jan 15, 2026 at 2:49 PM Clebert Suconic <[email protected]> wrote: > > 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 -- Clebert Suconic --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
