GitHub user mattrpav edited 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.
4. Wireformat fields and commands using terms 'master' and 'slave'
5. Network connector transport 'masterslave'

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 boolean 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.
6. 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


Reply via email to