[PROPOSAL] Terminology update

[mattrpav]

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.
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)

[jbonofre]

That sounds like a good plan.

Actually, master/slave is not heavily used in the code base, it's more in the documentation.

Maybe we can already use active/passive (instead of master/slave) on the codebase (probably fast to do).