on a second though, I could have the leadership inside the server.
What is making it difficult to figure out the best config, is because
the lock could apply to just part of the server. On the case of dual
mirror both brokers are "active" and only the acceptor serving the
clients will be on or off, while the same thing could be used to
active the server or not...
(I don't actually need to start the server based on this new
leadership thing... I'm only interested on applying this to
acceptors.. I'm only offering to replace the current activation as I
think it would be nicer this way... I could only apply this mechanism
on acceptors for now)
<core...>
<lead-exclusive>true | false</lead-exclusive>
<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>
<acceptor leade-exclusive="true | false"/>
</core>
On Thu, Jan 15, 2026 at 4:09 PM Clebert Suconic
<[email protected]> wrote:
>
> 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
--
Clebert Suconic
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
