so, I will park the idea for etcd for now.. I think fabric8 or the
kubernetes API makes a lot more sense.
What I am more concerned now is how to model the configuration for this..
I want to define a leadership entity that's independent of the
server... you can then apply it to acceptors or servers...
for servers I thought about just starting or stopping the server and
not even start the web console.. but if you want the web console
active... I can make that a detail on the implementation, the XML
would still be the same..
The current idea I have is the following:
<leadership name="my-leadership" type="kubernetes">
<properties>
<property name="name" value="my-app-lock"/>
<property name="namespace" value = "default"/>
<property name="leaseDuration" value="15"/>
<property name="checkPeriod" value="5"/>
</properties>
</leadership>
<core xmlns="urn:activemq:core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="urn:activemq:core " leadership="my-leadership">
(notice leadership is applied to the core element here..
And on the acceptor that should be activated based on the leadership:
<acceptor name="artemis"
leadership="my-leadership">tcp://0.0.0.0:61616..... </acceptor>
Why I'm doing that? because I could have mirroring replacing
replication, and the acceptor that will serve clients will only be
active in one of the servers...
The other option I had was to declare a locking on the acceptor.. but
I can see users defining multiple acceptors and wanting the whole
group activated or not.
this is the XML example I have in mind:
https://gist.github.com/clebertsuconic/cd01552f9a48b8d71695637fd9a5c949
On Thu, Jan 15, 2026 at 3:45 PM Clebert Suconic
<[email protected]> wrote:
>
> @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
--
Clebert Suconic
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
