Hi Matt, thanks for the proposal.
Personally, I'm still skeptical about this kind of changes for "technical wording".
If we really want to change, I think active/passive is the most accurate for kahadb/store HA, both runtime mode and status. Anyway, in ActiveMQ, we don't have concrete wording in the configuration (it's more in the code).
So, +1 with the proposal, +0 for change (I see more drawback than benefit). Regards JB On 7/12/21 7:40 PM, Matt Pavlovich wrote:
[Abstract] ActiveMQ 5 and Artemis are both re-working legacy terminology to better describe function and move away from problematic language for shared storage and replication terminology indicators. [Background] JIRA discussion: https://issues.apache.org/jira/browse/AMQ-7514 <https://issues.apache.org/jira/browse/AMQ-7514> Mailing list: http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html <http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html> [Proposal] P-1. Broker layer will maintain a status— ‘active’ or ’standby’ based on signals from persistence layerP-2. Persistence layer will optionally provide a noun and verb based on the underlying technology's terminology.P-3. ActiveMQ project created persistence layers that support replication, the terminology should attempt to provide noun and verb terms to describe the mode and state. Mode: ‘primary’ and ‘replica’ Status: ‘active’ and ’standby' [Scope] S-1. Terminology alignment between ActiveMQ 5 and Artemis is only for shared storage, replicated storage, broker status, and future terms. [Benefits] B-1. Terms for Broker state will be aligned between ActiveMQ 5 and Artemis free of problematic language. B-2. Terms for replication will bubble up “as-is” based on the underlying persistence layer technology. B-3. If both ActiveMQ 5 and Artemis use the same replication tech, then terms will be aligned. B-4. If one provides a persistence layer adapter that the other does not there is no phantom noun or verb present on the other broker that has no direct technical meaning [Rationale] R-1. Attempting to create common terms may leave one broker with a phantom term that has no meaningR-2. Attempting to create common terms is problematic when two supported persistence adapter layer technology use different terms (leader / follower, vs primary / replica).R-3. Renaming terminology that is not problematic for the sake of alignment (ie. acceptor vs transportConnector) unfairly creates burden on the existing user base. Thank you, -Matt Pavlovich
-- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
