[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17377861#comment-17377861
]
Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:05 AM:
--------------------------------------------------------------------
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back. The broker
service still has the capability to re-add it because whilst level db was
removed seperation between master and slave and if passive is still in broker
service, so re-adding a different replication solution without issue.
e.g. this is sample classic config that was for pure master slave, back in
leveldb time.
{code:java}
<broker masterConnectorURI="tcp://masterhost:62001"
shutdownOnMasterFailure="false">
<persistenceAdapter>
<journaledJDBC journalLogFiles="5"
dataDirectory="${activemq.base}/data/broker2" />
</persistenceAdapter>
<transportConnectors>
<transportConnector uri="tcp://slavehost:61616"/>
</transportConnectors>
</broker>
{code}
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
was (Author: michael.andre.pearce):
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back. The broker
service still has the capability to re-add it because whilst level db was
removed seperation between master and slave and if passive is still in broker
service, so re-adding a different replication solution without issue.
e.g. this is sample classic config that was for pure master slave, back in
leveldb time.
{code:java}
<broker masterConnectorURI="tcp://masterhost:62001"
shutdownOnMasterFailure="false">
<persistenceAdapter>
<journaledJDBC journalLogFiles="5"
dataDirectory="${activemq.base}/data/broker2" />
</persistenceAdapter>
<transportConnectors>
<transportConnector uri="tcp://slavehost:61616"/>
</transportConnectors>
</broker>
{code}
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
It
> Replace racially charged terms throughout source code, comments and
> documentation
> ---------------------------------------------------------------------------------
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
> Reporter: Bruce Snyder
> Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
