Regarding the "future replication capabilities"...Is there any sense that such a feature would require a "configured state" (which currently isn't required)? If so, should that influence this discussion at all?
Justin On Wed, Apr 15, 2026 at 12:51 PM mattrpav (via GitHub) <[email protected]> wrote: > > > GitHub user mattrpav created a discussion: [PROPOSAL] Terminology update > > ### Introduction > > The current terminology used by the broker mixes functional topics and has > been flagged as problematic language. > > Currently the term 'master' is overloaded to describe: > > 1. If a broker is active. > 2. If a data store is active. > 3. Stale code identifying a broker as a master in a master-master replication > scenario. > > Updating the terminology to separate technical capabilities, while addressing > problematic language will help ActiveMQ users have clearer understanding and > setup for future replication capabilities > > ### Proposal > > 1. Simple single flag if a broker is online to receive messaging traffic > a. transport connectors online > b. data store available for storing messages > > 2. Delegate message store status to the messages store implementation. > a. Example, a database is offline, the JDBCPersistenceAdapter could signal > a failure vs simple not obtaining the lock. Currently, both these concepts > are combined to put the broker into 'slave' mode > b. Example, kahadb lock obtain NFS lock vs failure to write to local disk > kicking of the IOExceptionHandler both put broker in 'slave' mode. > > #### Broker active > > 1. Simple metric (active=true) at the broker level that signals if the broker > is active (transport connectors online, datastore available). > 2. This replaces and deprecates the 'slave' flag. > 3. Broker starts up, active=false. Once datastore is available, broker may > move active=true. > 4. Administratively, a broker may receive a command to go 'offline' to stop > transport connectors and stop the data store from processing messages > > #### Message Store status > > 1. Each message store may provide their own flags > 2. Some flags may be inherited when it makes sense for the data store > technology -- Example: active=true|false, mode=primary|failover may be shared > by the JDBC and KahaDB stores. > 3. Future data stores can provide more details for replication suc h as > leader, follower, replication status, etc. > > #### Implementation approach > > 1. Add a new flag to the broker and datastore > 2. Mark broker's 'slave' flag as deprecated > 3. Add new non-impacting technical (JMX, web console, etc) user facing labels > using 'master' and 'slave' to 'Active' is True or False. Old fields remain > and get marked as @Deprecated for removal. In the case of a webpage, a > redirect may be added (ex: slave.jsp -> inactive.jsp) > > GitHub link: https://github.com/apache/activemq/discussions/1933 > > ---- > This is an automatically sent email for [email protected]. > To unsubscribe, please send an email to: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > For further information, visit: https://activemq.apache.org/contact > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
