From c1ba0673e1e917917f3f3169334d1e15618b4748 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lucas=20T=C3=A9treault?= Date: Mon, 16 May 2022 14:09:34 -0700 Subject: [PATCH] [AMQ-7514] Replace non-inclusive terms in classic docs --- src/_5x_releases/activemq-5002000-release.md | 6 +- src/_5x_releases/activemq-5008000-release.md | 4 +- src/_5x_releases/activemq-5009000-release.md | 6 +- src/_5x_releases/activemq-5009001-release.md | 6 +- .../inclusive-terminology-notice.html | 3 + src/_news/inclusive-terminology.md | 14 +++ src/activemq-artemis-roadmap.md | 9 +- src/activepassive.md | 24 +++++ src/advisory-message.md | 3 +- src/books.md | 4 +- ...can-two-brokers-share-the-same-database.md | 3 +- src/changes-in-40.md | 4 +- src/clustering.md | 7 +- src/examples.md | 3 +- src/exclusive-consumer.md | 3 +- src/features.md | 10 +- ...n-i-get-the-source-code-from-subversion.md | 4 +- src/how-do-distributed-queues-work.md | 14 +-- ...-configure-distributed-queues-or-topics.md | 7 +- ...do-i-embed-a-broker-inside-a-connection.md | 3 +- src/how-does-activemq-compare-to-mantaray.md | 3 +- ...master-slave.md => jdbc-active-passive.md} | 36 ++++--- src/jndi-support.md | 2 +- ...ster-slave.md => kahadb-active-passive.md} | 31 +++--- src/kahadb-replication-experimental.md | 27 ++--- src/masterslave.md | 21 ---- src/message-groups.md | 2 +- src/new-features-in-41.md | 5 +- src/new-features-in-52.md | 5 +- src/new-features-in-58.md | 3 +- src/new-features-in-59.md | 5 +- src/per-destination-policies.md | 2 +- src/persistence.md | 4 +- src/pluggable-storage-lockers.md | 24 ++--- src/pure-active-passive.md | 98 +++++++++++++++++++ src/pure-master-slave.md | 94 ------------------ src/replicated-leveldb-store.md | 21 ++-- src/replicated-message-store.md | 7 +- src/rest.md | 2 +- ...d => shared-file-system-active-passive.md} | 40 ++++---- src/sitemap.md | 7 +- src/source.md | 4 +- src/svn.md | 4 +- src/sybase.md | 3 +- src/test.md | 4 +- src/version-5-examples.md | 2 +- ...tion-solution-works-best-with-activemq-.md | 16 --- src/xbean-xml-reference-50.md | 10 +- 48 files changed, 339 insertions(+), 280 deletions(-) create mode 100644 src/_includes/inclusive-terminology-notice.html create mode 100644 src/_news/inclusive-terminology.md create mode 100644 src/activepassive.md rename src/{jdbc-master-slave.md => jdbc-active-passive.md} (67%) rename src/{kahadb-master-slave.md => kahadb-active-passive.md} (58%) delete mode 100644 src/masterslave.md create mode 100644 src/pure-active-passive.md delete mode 100644 src/pure-master-slave.md rename src/{shared-file-system-master-slave.md => shared-file-system-active-passive.md} (58%) delete mode 100644 src/what-open-source-integration-solution-works-best-with-activemq-.md diff --git a/src/_5x_releases/activemq-5002000-release.md b/src/_5x_releases/activemq-5002000-release.md index 69c3ac39d5..badc1bb9d2 100644 --- a/src/_5x_releases/activemq-5002000-release.md +++ b/src/_5x_releases/activemq-5002000-release.md @@ -9,6 +9,8 @@ redirect_from: [Overview](overview) > [Download](download) > [ActiveMQ 5.2.0 Release](activemq-520-release) +{% include inclusive-terminology-notice.html %} +
This is an older release. To get the current release, please see the download page.
@@ -24,12 +26,12 @@ New Features in 5.2 The new features and enhancements in this release include: -* [Additional advisory messages](Message FeaturesFeatures/Message Features/Features/Message Features/advisory-message) for messages delivered/consumed fast producers/slow consumers, Usage limits, Slaves become masters etc. +* [Additional advisory messages](Message FeaturesFeatures/Message Features/Features/Message Features/advisory-message) for messages delivered/consumed fast producers/slow consumers, Usage limits, Passive brokers become Active brokers etc. * Enhanced ssl context configuration through spring/xbean * New individual acknowledge mode for message consumption * Ability to configure the automatic discarding of the items being sent to the dead letter queue * Ability to limit the maximum number of connections to a Broker -* Ability to configure [separate lock](https://issues.apache.org/activemq/browse/AMQ-1244) Datasource for JDBC Master slave. +* Ability to configure [separate lock](https://issues.apache.org/activemq/browse/AMQ-1244) Datasource for JDBC Active Passive. * activemq-camel and activemq-connection-pool now have their own modules, no longer in activemq-core * The default [ActiveMQConnectionFactory](http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html) brokerUrl now uses the [failover transport](failover-transport-reference). * Uses Apache Camel [1.5](http://activemq.apache.org/camel/camel-150-release.html). diff --git a/src/_5x_releases/activemq-5008000-release.md b/src/_5x_releases/activemq-5008000-release.md index 3f2c97c251..b00958605d 100644 --- a/src/_5x_releases/activemq-5008000-release.md +++ b/src/_5x_releases/activemq-5008000-release.md @@ -9,6 +9,8 @@ redirect_from: [Overview](overview) > [Download](download) > [ActiveMQ 5.8.0 Release](activemq-580-release) +{% include inclusive-terminology-notice.html %} +
This is an older release. To get the current release, please see the download page.
@@ -20,7 +22,7 @@ Apache ActiveMQ 5.8.0 resolves [160 issues](https://issues.apache.org/jira/secur * management via [REST](ProtocolsConnectivity/Protocols/Connectivity/Protocols/rest) with [jolokia](http://www.jolokia.org/) jmx to http bridge * Includes [Apache Camel 2.10.3](http://camel.apache.org/camel-2103-release.html) * Java 7 support (compiled with jdk6 and validated with jdk7) -* [Pure Master Slave](pure-master-slave) no longer supported +* [Pure Active Passive](pure-active-passive) no longer supported There are some changes in 5.8 that may require some code change diff --git a/src/_5x_releases/activemq-5009000-release.md b/src/_5x_releases/activemq-5009000-release.md index 1797cb82c8..65ee725ebb 100644 --- a/src/_5x_releases/activemq-5009000-release.md +++ b/src/_5x_releases/activemq-5009000-release.md @@ -9,18 +9,20 @@ redirect_from: [Overview](overview) > [Download](download) > [ActiveMQ 5.9.0 Release](activemq-590-release) +{% include inclusive-terminology-notice.html %} +
This is an older release. To get the current release, please see the download page.
Apache ActiveMQ 5.9.0 resolves [more than 200 issues](https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+AMQ+AND+fixVersion+%3D+%225.9.0%22+AND+status+%3D+Resolved+ORDER+BY+priority+DESC&mode=hide), mostly bug fixes and improvements. It has the following new features: -* [Replicated LevelDB Store](replicated-Features/PersistenceFeatures/Persistence/Features/Persistence/leveldb-store) for shared nothing Master/Slave. +* [Replicated LevelDB Store](replicated-Features/PersistenceFeatures/Persistence/Features/Persistence/leveldb-store) for shared nothing Active/Passive. * [Runtime Configuration](New Features/New Features in 5.9/runtime-Community/FAQ/configuration) * Generic JMS XA connection pool in activemq-jms-pool module (has no ActiveMQ dependency) * MQTT over WebSockets support * [**broker**](FeaturesFeatures/Features/broker-camel-component) Apache Camel component -* Broker auto-restart upon losing master status +* Broker auto-restart upon losing active status * AMQP Hardening * LevelDB Hardening diff --git a/src/_5x_releases/activemq-5009001-release.md b/src/_5x_releases/activemq-5009001-release.md index abcb77ddd2..59e27b3b7d 100644 --- a/src/_5x_releases/activemq-5009001-release.md +++ b/src/_5x_releases/activemq-5009001-release.md @@ -9,18 +9,20 @@ redirect_from: [Overview](overview) > [Download](download) > [ActiveMQ 5.9.1 Release](activemq-591-release) +{% include inclusive-terminology-notice.html %} +
This is an older release. To get the current release, please see the download page.
Apache ActiveMQ 5.9.1 resolves [more than 120 issues](https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+AMQ+AND+fixVersion+%3D+%225.9.1%22+AND+status+%3D+Resolved+ORDER+BY+priority+DESC&mode=hide), mostly bug fixes and improvements. It has the following new features: -* [Replicated LevelDB Store](replicated-Features/PersistenceFeatures/Persistence/Features/Persistence/leveldb-store) for shared nothing Master/Slave. +* [Replicated LevelDB Store](replicated-Features/PersistenceFeatures/Persistence/Features/Persistence/leveldb-store) for shared nothing Active/Passive. * [Runtime Configuration](New Features/New Features in 5.9/runtime-Community/FAQ/configuration) * Generic JMS XA connection pool in activemq-jms-pool module (has no ActiveMQ dependency) * MQTT over WebSockets support * [**broker**](FeaturesFeatures/Features/broker-camel-component) Apache Camel component -* Broker auto-restart upon losing master status +* Broker auto-restart upon losing active status * AMQP Hardening * LevelDB Hardening diff --git a/src/_includes/inclusive-terminology-notice.html b/src/_includes/inclusive-terminology-notice.html new file mode 100644 index 0000000000..3a25fa3dc0 --- /dev/null +++ b/src/_includes/inclusive-terminology-notice.html @@ -0,0 +1,3 @@ +
+ This page has been updated to remove non-inclusive terminology. Please refer to the following announcement for more information: Replacing non-inclusive terms throughout source code, comments, and documentation +
\ No newline at end of file diff --git a/src/_news/inclusive-terminology.md b/src/_news/inclusive-terminology.md new file mode 100644 index 0000000000..e63b5d7dcf --- /dev/null +++ b/src/_news/inclusive-terminology.md @@ -0,0 +1,14 @@ +--- +release_date: 2022-05-13 +title: Replacing non-inclusive terms throughout source code, comments, and documentation +shortDescription: +title-class: page-title-main +type: main +--- +#### Replacing non-inclusive terms throughout source code, comments, and documentation +Moving forward, we will replace master/slave with 2 nouns to denote configured state and 2 adjectives to denote runtime state, and we will need to use those consistently across code and documentation for both brokers as follows: + +**Nouns:** Primary/Backup +**Adjectives:** Active/Passive + +These changes will take time to fully implement so please bear with us during this transition. \ No newline at end of file diff --git a/src/activemq-artemis-roadmap.md b/src/activemq-artemis-roadmap.md index 8c5b185e68..be4a7cd2fe 100644 --- a/src/activemq-artemis-roadmap.md +++ b/src/activemq-artemis-roadmap.md @@ -4,6 +4,7 @@ title: Artemis' Roadmap to ActiveMQ Next title-class: page-title-main type: main --- +{% include inclusive-terminology-notice.html %} The goal of this page is to identify the outstanding issues that must be addressed by Artemis in order to achieve feature parity with ActiveMQ "Classic". The overall objective for working toward feature parity between "Classic" and Artemis is for Artemis to eventually become the next major version of ActiveMQ. This page exists so that we can work together as a group to achieve this goal. This page does **not** list the features which Artemis has *beyond* what currently exists in ActiveMQ "Classic". @@ -27,7 +28,7 @@ Keep in mind that not every feature must have a ✅. Artemis may still be re |Feature|Artemis Support|JIRA|Notes| |---|:---:|---|---| -|[Broker Camel Component](broker-camel-component)|✅||[example](https://github.com/apache/activemq-artemis/tree/master/examples/features/standard/camel)| +|[Broker Camel Component](broker-camel-component)|✅||[example](https://github.com/apache/activemq-artemis/tree/main/examples/features/standard/camel)| |[Discovery](discovery)|✅||[UDP multicast & JGroups](components/artemis/documentation/latest/using-jms)| |[Enterprise Integration Patterns](enterprise-integration-patterns)|✅||see "Broker Camel Component"| |[Horizontal Scaling](horizontal-scaling)|✅||supported via [clustering](components/artemis/documentation/latest/clusters) or [federation](components/artemis/documentation/latest/federation)| @@ -44,7 +45,7 @@ Keep in mind that not every feature must have a ✅. Artemis may still be re |Feature|Artemis Support|JIRA|Notes| |---|:---:|---|---| -|[Master-slave](masterslave)|✅||using JDBC, shared filesystem, & replication; [documentation](components/artemis/documentation/latest/ha)| +|[Active-passive](activepassive)|✅||using JDBC, shared filesystem, & replication; [documentation](components/artemis/documentation/latest/ha)| |[Network of brokers](networks-of-brokers)|✅|[ARTEMIS-2265](https://issues.apache.org/jira/browse/ARTEMIS-2265)|equivalent through [clustering](components/artemis/documentation/latest/clusters) or [federation](components/artemis/documentation/latest/federation)| |[Replicated message store](replicated-message-store)|✅||equivalent via [replication](components/artemis/documentation/latest/ha) HA config| @@ -137,5 +138,5 @@ Migration This section should help to answer the end user question, _'How do I migrate from ActiveMQ "Classic" to Artemis?'_. This should include the identification of any tools that can help make this easier, as well as documenting information and procedures specific to migrating. * [Migration Guide](components/artemis/migration) -* Export messages from KahaDB using [this tool](https://github.com/apache/activemq-cli-tools/tree/master/activemq-kahadb-exporter). The exported XML can be imported via the `./artemis data imp` command. -* For non-standard backends (where direct export isn't an option) follow [this example](https://github.com/apache/activemq-artemis/tree/master/examples/features/sub-modules/inter-broker-bridge/artemis-jms-bridge) to migrate messages from ActiveMQ "Classic" to Artemis over the wire. +* Export messages from KahaDB using [this tool](https://github.com/apache/activemq-cli-tools/tree/main/activemq-kahadb-exporter). The exported XML can be imported via the `./artemis data imp` command. +* For non-standard backends (where direct export isn't an option) follow [this example](https://github.com/apache/activemq-artemis/tree/main/examples/features/sub-modules/inter-broker-bridge/artemis-jms-bridge) to migrate messages from ActiveMQ "Classic" to Artemis over the wire. diff --git a/src/activepassive.md b/src/activepassive.md new file mode 100644 index 0000000000..d96b7400ad --- /dev/null +++ b/src/activepassive.md @@ -0,0 +1,24 @@ +--- +layout: default_md +title: ActivePassive +title-class: page-title-activemq5 +type: activemq5 +redirect_from: +- /masterslave +--- + [Features](features) > [Clustering](clustering) > [ActivePassic](activepassive) + +{% include inclusive-terminology-notice.html %} + +Introduction to Active / Passive +------------------------------ + +The following are the different kinds of Active/Passive configurations available: + +Active Passive Type|Requirements|Pros|Cons +---|---|---|--- +[Shared File System Active Passive](shared-file-system-active-passive)|A shared file system such as a SAN|Run as many passive brokers as required. Automatic recovery of old active brokers|Requires shared file system +[JDBC Active Passive](jdbc-active-passive)|A Shared database|Run as many passive brokers as required. Automatic recovery of old active brokers|Requires a shared database. Also relatively slow as it cannot use the high performance journal + +If you are using a shared network file system such as a SAN we recommend a [Shared File System Active Passive](shared-file-system-active-passive). If you are happy to dispense with the high performance journal and are using pure JDBC as your persistence engine then you should use [JDBC Active Passive](jdbc-active-passive) instead. + diff --git a/src/advisory-message.md b/src/advisory-message.md index 7abd7b6d2d..f0c5c69a47 100644 --- a/src/advisory-message.md +++ b/src/advisory-message.md @@ -7,6 +7,7 @@ type: activemq5 [Features](features) > [Message Features](message-features) > [Advisory Message](advisory-message) +{% include inclusive-terminology-notice.html %} ActiveMQ supports advisory messages which allows you to watch the system using regular JMS messages. Currently we have advisory messages that support: @@ -101,7 +102,7 @@ Advisory Topics|Description|Properties|Data Structure|Default|PolicyEntry Proper `ActiveMQ.Advisory.MessageConsumed.Queue`|Message consumed by a client.|`String='orignalMessageId'` - the delivered id|`Message`|`false`|`advisoryForConsumed` `ActiveMQ.Advisory.MessageConsumed.Topic`|Message consumed by a client.|`String='orignalMessageId'` - the delivered id|`Message`|`false`|`advisoryForConsumed` `ActiveMQ.Advisory.FULL`|A Usage resource is at its limit.|`String='usageName'` - the name of Usage resource|`null`|`false`|`advisoryWhenFull` -`ActiveMQ.Advisory.MasterBroker`|A broker is now the master in a master/slave configuration.|`null`|`null`|`true`|`none` +`ActiveMQ.Advisory.MasterBroker`|A broker is now the active broker in an active/passive configuration.|`null`|`null`|`true`|`none` ### New Advisories in 5.4 diff --git a/src/books.md b/src/books.md index 5180dbaf4f..9136b2a159 100644 --- a/src/books.md +++ b/src/books.md @@ -7,6 +7,8 @@ type: activemq5 [Community](community) > [Books](books) +{% include inclusive-terminology-notice.html %} + Books ===== @@ -47,5 +49,5 @@ Learn how to use messaging technologies to build responsive and resilient applic ### Apache ActiveMQ Reference Guide Kit -The TTM's "[Apache ActiveMQ Reference Guide](http://www.ttmsolutions.com/Apache_Software/ActiveMQ_Reference_Guide.php)" (PDF book) provides information to learn how to implement, deploy, administer, and tune Apache ActiveMQ. The Reference Guide includes details on how to work with ActiveMQ components, connectors, client/broker configuration, master/slave configuration, administration, logging, performance tuning and advanced features. +The TTM's "[Apache ActiveMQ Reference Guide](http://www.ttmsolutions.com/Apache_Software/ActiveMQ_Reference_Guide.php)" (PDF book) provides information to learn how to implement, deploy, administer, and tune Apache ActiveMQ. The Reference Guide includes details on how to work with ActiveMQ components, connectors, client/broker configuration, active/passive configuration, administration, logging, performance tuning and advanced features. diff --git a/src/can-two-brokers-share-the-same-database.md b/src/can-two-brokers-share-the-same-database.md index 6093f542b5..7ff66475d6 100644 --- a/src/can-two-brokers-share-the-same-database.md +++ b/src/can-two-brokers-share-the-same-database.md @@ -7,6 +7,7 @@ type: activemq5  [FAQ](faq) > [Using Apache ActiveMQ](using-apache-activemq) > [Can two brokers share the same database](can-two-brokers-share-the-same-database) +{% include inclusive-terminology-notice.html %} Can two brokers share the same database --------------------------------------- @@ -15,5 +16,5 @@ The short answer is no; 2 brokers cannot operate on the same sets of database ta If you want to share the same physical database server across two brokers to simplify your installation & backup procedures then just create 2 different logins for each broker so that they get their own sets of database tables within the same physical database. (i.e. each broker gets its own logical database within the same physical database server). -Also if you want to only have one database but many possible brokers (for HA) then just use [JDBC Master Slave](jdbc-master-slave) +Also if you want to only have one database but many possible brokers (for HA) then just use [JDBC Active Passive](jdbc-active-passive) diff --git a/src/changes-in-40.md b/src/changes-in-40.md index 7a2f59ecb3..038eb6ea52 100644 --- a/src/changes-in-40.md +++ b/src/changes-in-40.md @@ -7,9 +7,11 @@ type: activemq5 [Features](features) > [New Features](new-features) > [Changes in 4.0](changes-in-40) +{% include inclusive-terminology-notice.html %} + ### New Features in 4.0 -* [MasterSlave](masterslave) provides support for continuous availability and fault tolerance of brokers to be able to handle catastrophic hardware failure and not loose a message (or get duplicates). +* [ActivePassive](activepassive) provides support for continuous availability and fault tolerance of brokers to be able to handle catastrophic hardware failure and not loose a message (or get duplicates). * A new [Exclusive Consumer](exclusive-consumer) feature allows you to pin message processing to a single consumer in a cluser of consumers. * A new [Message Groups](message-groups) feaure allows you load balance messages accross a set of consumers but also garantee the message order for messages within a message group. * A new [Total Ordering](total-ordering) feature to allow all consumers on a topic to see messages in the same order. diff --git a/src/clustering.md b/src/clustering.md index b817965a09..8979662697 100644 --- a/src/clustering.md +++ b/src/clustering.md @@ -7,6 +7,7 @@ type: activemq5 [Features](features) > [Clustering](clustering) +{% include inclusive-terminology-notice.html %} Clustering is a large topic and often means different things to different people. We'll try to list the various aspects of clustering and how they relate to ActiveMQ @@ -50,17 +51,17 @@ Networks of brokers also allows us to scale up to a massive number of clients in You can think of this as a cluster of clients connecting with a cluster of brokers with auto-failover and discovery, making a simple and easy to use messaging fabric. -Master Slave +Active Passive ------------ The problem with running lots of stand alone brokers or brokers in a network is that messages are owned by a single physical broker at any point in time. If that broker goes down, you have to wait for it to be restarted before the message can be delivered. (If you are using non-persistent messaging and a broker goes down you generally lose your message). -The idea behind [MasterSlave](masterslave) is that messages are replicated to a slave broker so that even if you have a catastrophic hardware failure of the master's machine, file system or data centre, you get immediate failover to the slave with no message loss. +The idea behind [ActivePassive](activepassive) is that messages are replicated to a passive broker so that even if you have a catastrophic hardware failure of the active broker's machine, file system or data centre, you get immediate failover to the passive broker with no message loss. Replicated Message Stores ------------------------- -An alternative to [MasterSlave](masterslave) is to have some way to replicate the message store; so for the disk files to be shared in some way. For example using a SAN or shared network drive you can share the files of a broker so that if it fails another broker can take over straight away. +An alternative to [ActivePassive](activepassive) is to have some way to replicate the message store; so for the disk files to be shared in some way. For example using a SAN or shared network drive you can share the files of a broker so that if it fails another broker can take over straight away. So by supporting a [Replicated Message Store](replicated-message-store) you can reduce the risk of message loss to provide either a HA backup or a full [DR](dr) solution capable of surviving a data centre failure. diff --git a/src/examples.md b/src/examples.md index 10d454adf3..b5d6d92a23 100644 --- a/src/examples.md +++ b/src/examples.md @@ -7,6 +7,7 @@ type: activemq5 [Using ActiveMQ](using-activemq) > [Examples](examples) +{% include inclusive-terminology-notice.html %} Since version **5.12.0**, Apache ActiveMQ comes with the new tool that can be used to produce and consume messages from the broker. @@ -41,7 +42,7 @@ activemq:consumer Options ------- -For all options on the commands, run them with `--help` parameter. The up to date, options for [producer](https://github.com/apache/activemq/blob/master/activemq-console/src/main/resources/org/apache/activemq/console/command/producer.txt) and [consumer](https://github.com/apache/activemq/blob/master/activemq-console/src/main/resources/org/apache/activemq/console/command/consumer.txt) can be found in the source. +For all options on the commands, run them with `--help` parameter. The up to date, options for [producer](https://github.com/apache/activemq/blob/main/activemq-console/src/main/resources/org/apache/activemq/console/command/producer.txt) and [consumer](https://github.com/apache/activemq/blob/main/activemq-console/src/main/resources/org/apache/activemq/console/command/consumer.txt) can be found in the source. Examples -------- diff --git a/src/exclusive-consumer.md b/src/exclusive-consumer.md index 3bc988286a..c7168b59cf 100644 --- a/src/exclusive-consumer.md +++ b/src/exclusive-consumer.md @@ -7,6 +7,7 @@ type: activemq5 [Features](features) > [Consumer Features](consumer-features) > [Exclusive Consumer](exclusive-consumer) +{% include inclusive-terminology-notice.html %} ### Background @@ -20,7 +21,7 @@ So what folks have to do in J2EE clusters is often to _pin_ one particular JVM i We have a new feature in 4.x called Exclusive Consumer or Exclusive Queues which avoids the end user having to _pin_ anything. The broker will pick a single MessageConsumer to get all the messages for a queue to ensure ordering. If that consumer fails, the broker will auto failover and choose another consumer. -So the effect is a heterogeneous J2EE cluster where each JVM has the same setup and configuration; the broker is choosing one consumer to be the _master_ and send all the messages to it in order until it dies; then you get immediate failover to another consumer. +So the effect is a heterogeneous J2EE cluster where each JVM has the same setup and configuration; the broker is choosing one consumer to be the _active consumer_ and send all the messages to it in order until it dies; then you get immediate failover to another consumer. For those who've struggled with pinning JMS consumers in J2EE clusters you'll immediately realize how useful this is to making clustered, high available distributed services. diff --git a/src/features.md b/src/features.md index 09fcb990bc..9c93da4283 100644 --- a/src/features.md +++ b/src/features.md @@ -7,6 +7,8 @@ type: activemq5 [Features](features) +{% include inclusive-terminology-notice.html %} + Apache ActiveMQ Features ------------------------ @@ -20,11 +22,11 @@ Apache ActiveMQ is packed with features; to get an idea you might want to look a * [The ActiveBlaze Message type](the-activeblaze-message-type) * [Broker Camel Component](broker-camel-component) * [Clustering](clustering) - * [MasterSlave](masterslave) - * [JDBC Master Slave](jdbc-master-slave) + * [ActivePassive](activepassive) + * [JDBC Active Passive](jdbc-active-passive) * [KahaDB Replication (Experimental)](kahadb-replication-experimental) - * [Pure Master Slave](pure-master-slave) - * [Shared File System Master Slave](shared-file-system-master-slave) + * [Pure Active Passive](pure-active-passive) + * [Shared File System Active Passive](shared-file-system-active-passive) * [Networks of Brokers](networks-of-brokers) * [Replicated Message Store](replicated-message-store) * [Command Agent](command-agent) diff --git a/src/how-can-i-get-the-source-code-from-subversion.md b/src/how-can-i-get-the-source-code-from-subversion.md index 4522155fb8..cac691c87a 100644 --- a/src/how-can-i-get-the-source-code-from-subversion.md +++ b/src/how-can-i-get-the-source-code-from-subversion.md @@ -50,12 +50,12 @@ Checking out from the Github Repo git clone [https://github.com/apache/activemq-artemis](https://github.com/apache/activemq-artemis) -**Committers:** Please follow the instructions for properly configuring the [Instructions for Core Contributors/Hacking Guide](https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/en/SUMMARY.md) +**Committers:** Please follow the instructions for properly configuring the [Instructions for Core Contributors/Hacking Guide](https://github.com/apache/activemq-artemis/blob/main/docs/hacking-guide/en/SUMMARY.md) **Contributors:** Please create a [pull request](https://github.com/apache/activemq-artemis) to contribute changes to the source code.  Building the code ----------------- -To then build the code, take a look at [Building the distribution](https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/en/building.md) +To then build the code, take a look at [Building the distribution](https://github.com/apache/activemq-artemis/blob/main/docs/hacking-guide/en/building.md) diff --git a/src/how-do-distributed-queues-work.md b/src/how-do-distributed-queues-work.md index b0e2b8b9c2..354c6dc3e9 100644 --- a/src/how-do-distributed-queues-work.md +++ b/src/how-do-distributed-queues-work.md @@ -7,6 +7,7 @@ type: activemq5  [FAQ](faq) > [Using Apache ActiveMQ](using-apache-activemq) > [How do distributed queues work](how-do-distributed-queues-work) +{% include inclusive-terminology-notice.html %} There are various [Topologies](topologies) that you can employ with ActiveMQ, where clients are connected to message brokers in various ways like @@ -18,23 +19,24 @@ Each client communicates with a broker using some kind of [client library and ne To create distributed queues or topics we need to have the message brokers communicate with each other. There are two different types of broker to broker communication... -Master/Slave for High Availability +Active/Passive for High Availability ---------------------------------- -A [Master/Slave Cluster](masterslave) is used for [HA](ha). Basically it means that all messages are replicated across each broker in the master/slave cluster. If the Master goes down, the clients can automatically failover to a slave which will have all the messages already, so each message is highly available. The Slave(s) provide a hot standby broker which will always be in sync ready to take over if the master goes away due to hardware failure etc. +A [Active/Passive Cluster](activepassive) is used for [HA](ha). Basically it means that all messages are replicated across each broker in the active/passive cluster. If the active broker goes down, the clients can automatically failover to a passive broker which will have all the messages already, so each message is highly available. The passive broker(s) provide a hot standby broker which will always be in sync ready to take over if the active broker goes away due to hardware failure etc. -Master/Slave works by having some form of replication; each message is owned by every broker in the logical cluster. A master/slave cluster then acts as one logical message broker which could then be connected via store and forward to other brokers (as we'll see in the next section). +Active/Passive works by having some form of replication; each message is owned by every broker in the logical cluster. An active/passive cluster then acts as one logical message broker which could then be connected via store and forward to other brokers (as we'll see in the next section). ### Distributed Queues and Topics -In Master/Slave, queues and topics are all replicated between each broker in the cluster (so often to a master and maybe a single slave). So each broker in the cluster has exactly the same messages available at any time so if a master fails, clients failover to a slave and you don't loose a message. +In Active/Passive, queues and topics are all replicated between each broker in the cluster (so often to an active broker and maybe a single passive broker). So each broker in the cluster has exactly the same messages available at any time so if an active broker fails, clients failover to a passive broker and you don't +a message. Store and forward networks of brokers ------------------------------------- A [Store and Forward Network of Brokers](networks-of-brokers) means the messages travel from broker to broker until they reach a consumer; with each message being owned by a single broker at any point in time. When a JMS producer sends a message to a JMS consumer, it may travel through several brokers to reach its final destination. ActiveMQ uses [Consumer Priority](consumer-priority) so that local JMS consumers are always higher priority than remote brokers in a store and forward network. -Note though that a store and forward network is not a solution for message [HA](ha); if a broker fails in a Store and Forward network, the messages owned by that broker remain inside the broker's persistent store until the broker comes back online. If you need [HA](ha) of messages then you need to use Master/Slave described above. +Note though that a store and forward network is not a solution for message [HA](ha); if a broker fails in a Store and Forward network, the messages owned by that broker remain inside the broker's persistent store until the broker comes back online. If you need [HA](ha) of messages then you need to use Active/Passive described above. Store and forward is often used in large networks where producers are on one LAN and consumers are on another LAN and you wish to use a broker on each LAN as a kind of network concentrator to minimise chattiness over the WAN between them (and to minimise the number of connections required across the WAN too). Similar uses of store and forward can be found when using firewalls or SSL across certain networks etc. One other use case for store and forward networks is if your OS does not support many sockets (and you can't reconfigure that) you could use a store and forward network to connect massive numbers of clients together in one logical network. @@ -54,6 +56,6 @@ For topics the above algorithm is followed except, every interested client recei ### See Also * [How do I configure distributed queues or topics](how-do-i-configure-distributed-queues-or-topics) -* [MasterSlave](masterslave) +* [ActivePassive](activepassive) * [Networks of Brokers](networks-of-brokers) diff --git a/src/how-do-i-configure-distributed-queues-or-topics.md b/src/how-do-i-configure-distributed-queues-or-topics.md index f5b4fa4a2e..fda3f37757 100644 --- a/src/how-do-i-configure-distributed-queues-or-topics.md +++ b/src/how-do-i-configure-distributed-queues-or-topics.md @@ -7,21 +7,22 @@ type: activemq5  [FAQ](faq) > [Configuration](configuration) > [How do I configure distributed queues or topics](how-do-i-configure-distributed-queues-or-topics) +{% include inclusive-terminology-notice.html %} How do I configure distributed queues or topics ----------------------------------------------- -You don't need to explicitly [configure distributed queues or topics](how-do-i-configure-the-queues-i-want) as any queue or topic is automatically distributed across other brokers when the brokers are configured in either a store and forward network or a master/slave cluster. +You don't need to explicitly [configure distributed queues or topics](how-do-i-configure-the-queues-i-want) as any queue or topic is automatically distributed across other brokers when the brokers are configured in either a store and forward network or an active/passive cluster. So you just need to connect brokers together to form either * a [Store and Forward Network of Brokers](networks-of-brokers), which means the messages travel from broker to broker until they reach a consumer; with each message being owned by a single broker at any point in time -* a [Master/Slave Cluster](masterslave), which means all messages are replicated across each broker in the master/slave cluster +* a [Active/Passive Cluster](activepassive), which means all messages are replicated across each broker in the active/passive cluster ### Also see * [How do I configure the queues I want](how-do-i-configure-the-queues-i-want) * [How do distributed queues work](how-do-distributed-queues-work) * [Networks of Brokers](networks-of-brokers) -* [MasterSlave](masterslave) +* [ActivePassive](activepassive) diff --git a/src/how-do-i-embed-a-broker-inside-a-connection.md b/src/how-do-i-embed-a-broker-inside-a-connection.md index 6e8349595f..99d18ecd5e 100644 --- a/src/how-do-i-embed-a-broker-inside-a-connection.md +++ b/src/how-do-i-embed-a-broker-inside-a-connection.md @@ -7,6 +7,7 @@ type: activemq5  [FAQ](faq) > [Using Apache ActiveMQ](using-apache-activemq) > [How do I embed a Broker inside a Connection](how-do-i-embed-a-broker-inside-a-connection) +{% include inclusive-terminology-notice.html %} In many messaging topologies there are JMS Brokers (server side) and a JMS client side. Often it makes sense to deploy a broker within your JVM. This allows you to optimise away a network hop; making the networking of JMS as efficient as pure RMI, but with all the usual JMS features of location independence, reliability, load balancing etc. @@ -23,7 +24,7 @@ broker.addConnector("tcp://localhost:61616"); broker.start(); ``` -If you want to lazily bind the transport connector as part of start(), useful when start() will block pending a store lock (as in a slave start), you can use the following code +If you want to lazily bind the transport connector as part of start(), useful when start() will block pending a store lock (as in a passive broker start), you can use the following code ``` BrokerService broker = new BrokerService(); diff --git a/src/how-does-activemq-compare-to-mantaray.md b/src/how-does-activemq-compare-to-mantaray.md index 604093498b..dc04fde3e3 100644 --- a/src/how-does-activemq-compare-to-mantaray.md +++ b/src/how-does-activemq-compare-to-mantaray.md @@ -7,6 +7,7 @@ type: activemq5  [FAQ](faq) > [General](general) > [How does ActiveMQ compare to Mantaray](how-does-activemq-compare-to-mantaray) +{% include inclusive-terminology-notice.html %} We are obviously biased, and will tell you "just use ActiveMQ!" ![(smile)](https://cwiki.apache.org/confluence/s/en_GB/5997/6f42626d00e36f53fe51440403446ca61552e2a2.1/_/images/icons/emoticons/smile.png) But Mantaray is an OK JMS provider. The interesting thing about MantaRay is it can support a peer-based network, just as ActiveMQ does with its [peer transport](peer-transport-reference). @@ -14,5 +15,5 @@ We [benchmark](performance) against Mantaray and other open source JMS providers A peer transport can be useful when using non-persistent messaging. But if you want persistent messaging you often want to use a federated network with certain brokers on the network being the persistence brokers (so you can backup the file systems etc). -The ideal topology often depends on your requirements and how you want to manage persistence and deal with hardware failures such as with [MasterSlave](masterslave). +The ideal topology often depends on your requirements and how you want to manage persistence and deal with hardware failures such as with [ActivePassive](activepassive). diff --git a/src/jdbc-master-slave.md b/src/jdbc-active-passive.md similarity index 67% rename from src/jdbc-master-slave.md rename to src/jdbc-active-passive.md index fdc0c859dc..59bacd08a5 100644 --- a/src/jdbc-master-slave.md +++ b/src/jdbc-active-passive.md @@ -1,13 +1,17 @@ --- layout: default_md -title: JDBC Master Slave +title: JDBC Active Passive title-class: page-title-activemq5 type: activemq5 +redirect_from: +- /jdbc-master-slave --- - [Features](features) > [Clustering](clustering) > [MasterSlave](masterslave) > [JDBC Master Slave](jdbc-master-slave) + [Features](features) > [Clustering](clustering) > [ActivePassive](activepassive) > [JDBC Active Passive](jdbc-active-passive) -JDBC Master Slave +{% include inclusive-terminology-notice.html %} + +JDBC Active Passive ----------------- First supported in ActiveMQ version 4.1 @@ -16,7 +20,7 @@ If you are using pure JDBC and not using the high performance journal then you a ### Startup -When using just JDBC as the data source you can use a Master Slave approach, running as many brokers as you wish as this diagram shows. On startup one master grabs an exclusive lock in the broker database - all other brokers are slaves and pause waiting for the exclusive lock. +When using just JDBC as the data source you can use an Active Passive approach, running as many brokers as you wish as this diagram shows. On startup one active grabs an exclusive lock in the broker database - all other brokers are passives and pause waiting for the exclusive lock. ![](assets/img/Startup.png) @@ -24,29 +28,29 @@ Clients should be using the [Failover Transport](failover-transport-reference) t ``` failover:(tcp://broker1:61616,tcp://broker2:61616,tcp://broker3:61616) ``` -Only the master broker starts up its transport connectors and so the clients can only connect to the master. +Only the active broker starts up its transport connectors and so the clients can only connect to the active. -### Master failure +### Active failure -If the master looses connection to the database or looses the exclusive lock then it immediately shuts down. If a master shuts down or fails, one of the other slaves will grab the lock and so the topology switches to the following diagram +If the active loses connection to the database or loses the exclusive lock then it immediately shuts down. If an active shuts down or fails, one of the other passives will grab the lock and so the topology switches to the following diagram -![](assets/img/MasterFailed.png) +![](assets/img/ActiveFailed.png) -One of the other other slaves immediately grabs the exclusive lock on the database to them commences becoming the master, starting all of its transport connectors. +One of the other passives immediately grabs the exclusive lock on the database to them commences becoming the active, starting all of its transport connectors. -Clients loose connection to the stopped master and then the failover transport tries to connect to the available brokers - of which the only one available is the new master. +Clients lose connection to the stopped active and then the failover transport tries to connect to the available brokers - of which the only one available is the new active. -### Master restart +### Active restart -At any time you can restart other brokers which join the cluster and start as slaves waiting to become a master if the master is shutdown or a failure occurs. So the following topology is created after a restart of an old master... +At any time you can restart other brokers which join the cluster and start as passives waiting to become an active if the active is shutdown or a failure occurs. So the following topology is created after a restart of an old active... -![](assets/img/MasterRestarted.png) +![](assets/img/ActiveRestarted.png) -### Configuring JDBC Master Slave +### Configuring JDBC Active Passive -By default if you use the **** to avoid the high performance journal you will be using JDBC Master Slave by default. You just need to run more than one broker and point the client side URIs to them to get master/slave. This works because they both try an acquire an exclusive lock on a shared table in the database and only one will succeed. +By default if you use the **** to avoid the high performance journal you will be using JDBC Active Passive by default. You just need to run more than one broker and point the client side URIs to them to get active/passive. This works because they both try an acquire an exclusive lock on a shared table in the database and only one will succeed. -The following example shows how to configure the ActiveMQ broker in JDBC Master Slave mode +The following example shows how to configure the ActiveMQ broker in JDBC Active Passive mode ``` diff --git a/src/jndi-support.md b/src/jndi-support.md index 1ea0357954..7b73e35b5e 100644 --- a/src/jndi-support.md +++ b/src/jndi-support.md @@ -34,7 +34,7 @@ You can edit the `jndi.properties` file to configure the `ActiveMQConnectionFac ### ActiveMQ JNDI Tutorial -This is a quick one page tutorial on how to setup and use JNDI to create a connection to ActiveMQ. The first thing is ActiveMQ does not provide a full JNDI server. This means JMS clients need to use properties files to create a JNDI `IntialContextFactory`. If you need an example properties file, you can look the source distribution [https://github.com/apache/activemq/blob/master/activemq-unit-tests/src/test/resources/jndi.properties](https://github.com/apache/activemq/blob/master/activemq-unit-tests/src/test/resources/jndi.properties). Before we proceed, here are the properties. +This is a quick one page tutorial on how to setup and use JNDI to create a connection to ActiveMQ. The first thing is ActiveMQ does not provide a full JNDI server. This means JMS clients need to use properties files to create a JNDI `IntialContextFactory`. If you need an example properties file, you can look the source distribution [https://github.com/apache/activemq/blob/main/activemq-unit-tests/src/test/resources/jndi.properties](https://github.com/apache/activemq/blob/main/activemq-unit-tests/src/test/resources/jndi.properties). Before we proceed, here are the properties. Name|Value `java.naming.factory.initial`|`org.apache.activemq.jndi.ActiveMQInitialContextFactory` diff --git a/src/kahadb-master-slave.md b/src/kahadb-active-passive.md similarity index 58% rename from src/kahadb-master-slave.md rename to src/kahadb-active-passive.md index 11681c4f80..76fb0ca44e 100644 --- a/src/kahadb-master-slave.md +++ b/src/kahadb-active-passive.md @@ -1,12 +1,15 @@ --- layout: default_md -title: KahaDB Master Slave +title: KahaDB Active Passive title-class: page-title-activemq5 type: activemq5 +redirect_from: +- /kahadb-master-slave --- -[Features](features) > [Clustering](clustering) > [MasterSlave](masterslave) > [KahaDB Master Slave](kahadb-master-slave) +[Features](features) > [Clustering](clustering) > [ActivePassive](activepassive) > [KahaDB Active Passive](kahadb-active-passive) +{% include inclusive-terminology-notice.html %} > **Note** > @@ -17,19 +20,19 @@ Overview The new KahaDB store supports a very fast and flexible replication system. It features: -* Journal level replication (The translates into lower overhead to the master to replicate records). -* Support for multiple slaves. -* Support to dynamically add slaves at runtime. -* Uses multiple concurrent data transfer sessions to do an initial slave synchronization. -* Big slave synchronizations can be resumed so synchronization progress is not lost if a slave is restarted. +* Journal level replication (The translates into lower overhead to the active to replicate records). +* Support for multiple passives. +* Support to dynamically add passives at runtime. +* Uses multiple concurrent data transfer sessions to do an initial passive synchronization. +* Big passive synchronizations can be resumed so synchronization progress is not lost if a passive is restarted. * A configurable minimum number of replicas allows you to pause processing until the data has been guaranteed to be replicated enough times. -Master Election +Active Election --------------- -KahaDB supports a pluggable Master Election algorithm but the only current implementation is one based on [ZooKeeper](http://hadoop.apache.org/zookeeper). +KahaDB supports a pluggable Active Election algorithm but the only current implementation is one based on [ZooKeeper](http://hadoop.apache.org/zookeeper). -ZooKeeper is used to implement the master election algorithm. ZooKeeper is a very fast, replicated, in memory database with features that make it easy to implement cluster control algorithms. It is an Apache project which you can [freely download](http://hadoop.apache.org/zookeeper/releases.html). You must installed and have at least one ZooKeeper server running before setting up a KahaDB Master Slave configuration. +ZooKeeper is used to implement the active election algorithm. ZooKeeper is a very fast, replicated, in memory database with features that make it easy to implement cluster control algorithms. It is an Apache project which you can [freely download](http://hadoop.apache.org/zookeeper/releases.html). You must installed and have at least one ZooKeeper server running before setting up a KahaDB Active Passive configuration. Configuring a Broker: --------------------- @@ -54,20 +57,20 @@ Understanding the kahadbReplication XML element ### The brokerURI Attribute -Notice that the the brokerURI attribute points at another broker configuration file. The ha-broker.xml contains the actual broker configuration that the broker uses when the node take over as master. The ha-broker.xml configuration file is a standard broker configuration except in these aspects: +Notice that the brokerURI attribute points at another broker configuration file. The ha-broker.xml contains the actual broker configuration that the broker uses when the node take over as active. The ha-broker.xml configuration file is a standard broker configuration except in these aspects: * It MUST set the start="false" attribute on the broker element. * It MUST not configure a persistenceAdapter. -The above rules allows the replication system to inject the replicated KahaDB store into the Master when it's starting up. +The above rules allows the replication system to inject the replicated KahaDB store into the Active when it's starting up. ### The minimumReplicas Attribute -The minimumReplicas specifies how many copies of the database are required before synchronous update operations are deemed successful. Setting this to 0 allows a broker to continue operating even if there are no slaves attached. If the value is set to 1 or greater, and there are no slaves attached, the brokers persistent message processing will be suspended until the minimum number of slaves are attached and the data synchronized. +The minimumReplicas specifies how many copies of the database are required before synchronous update operations are deemed successful. Setting this to 0 allows a broker to continue operating even if there are no passives attached. If the value is set to 1 or greater, and there are no passives attached, the brokers persistent message processing will be suspended until the minimum number of passives are attached and the data synchronized. ### The uri Attribute -The uri attribute should always be configured with a **kdbr://** based URI. KDBR stands for 'KahaDB Replication' and this is the replication protocol used between the masters and the slaves. The master binds the specified port with slaves subsequently connect to and establish replication sessions. The host name in the uri MUST get updated to the actual machine's host name since this is also used to identify the nodes in the cluster. +The uri attribute should always be configured with a **kdbr://** based URI. KDBR stands for 'KahaDB Replication' and this is the replication protocol used between the actives and the passives. The active binds the specified port with passives subsequently connect to and establish replication sessions. The host name in the uri MUST get updated to the actual machine's host name since this is also used to identify the nodes in the cluster. ### The directory Attribute diff --git a/src/kahadb-replication-experimental.md b/src/kahadb-replication-experimental.md index 1b26ab0903..c73a5aeacc 100644 --- a/src/kahadb-replication-experimental.md +++ b/src/kahadb-replication-experimental.md @@ -5,8 +5,9 @@ title-class: page-title-activemq5 type: activemq5 --- -[Features](features) > [Clustering](clustering) > [MasterSlave](masterslave) > [KahaDB Replication (Experimental)](kahadb-replication-experimental) +[Features](features) > [Clustering](clustering) > [ActivePassive](activepassive) > [KahaDB Replication (Experimental)](kahadb-replication-experimental) +{% include inclusive-terminology-notice.html %} Note @@ -17,19 +18,19 @@ Overview The new KahaDB store supports a very fast and flexible replication system. It features: -* Journal level replication (The translates into lower overhead to the master to replicate records). -* Support for multiple slaves. -* Support to dynamically add slaves at runtime. -* Uses multiple concurrent data transfer sessions to do an initial slave synchronization. -* Big slave synchronizations can be resumed so synchronization progress is not lost if a slave is restarted. +* Journal level replication (The translates into lower overhead to the active broker to replicate records). +* Support for multiple passive brokers. +* Support to dynamically add passive brokers at runtime. +* Uses multiple concurrent data transfer sessions to do an initial passive broker synchronization. +* Big passive broker synchronizations can be resumed so synchronization progress is not lost if a passive broker is restarted. * A configurable minimum number of replicas allows you to pause processing until the data has been guaranteed to be replicated enough times. -Master Election +Active Election --------------- -KahaDB supports a pluggable Master Election algorithm but the only current implementation is one based on [ZooKeeper](http://hadoop.apache.org/zookeeper). +KahaDB supports a pluggable Active Broker Election algorithm but the only current implementation is one based on [ZooKeeper](http://hadoop.apache.org/zookeeper). -ZooKeeper is used to implement the master election algorithm. ZooKeeper is a very fast, replicated, in memory database with features that make it easy to implement cluster control algorithms. It is an Apache project which you can [freely download](http://hadoop.apache.org/zookeeper/releases.html). You must installed and have at least one ZooKeeper server running before setting up a KahaDB Master Slave configuration. +ZooKeeper is used to implement the active broker election algorithm. ZooKeeper is a very fast, replicated, in memory database with features that make it easy to implement cluster control algorithms. It is an Apache project which you can [freely download](http://hadoop.apache.org/zookeeper/releases.html). You must installed and have at least one ZooKeeper server running before setting up a KahaDB Active Passive configuration. Configuring a Broker: --------------------- @@ -49,20 +50,20 @@ Understanding the kahadbReplication XML element ### The brokerURI Attribute -Notice that the the brokerURI attribute points at another broker configuration file. The ha-broker.xml contains the actual broker configuration that the broker uses when the node take over as master. The ha-broker.xml configuration file is a standard broker configuration except in these aspects: +Notice that the the brokerURI attribute points at another broker configuration file. The ha-broker.xml contains the actual broker configuration that the broker uses when the node take over as the active broker. The ha-broker.xml configuration file is a standard broker configuration except in these aspects: * It MUST set the start="false" attribute on the broker element. * It MUST not configure a persistenceAdapter. -The above rules allows the replication system to inject the replicated KahaDB store into the Master when it's starting up. +The above rules allows the replication system to inject the replicated KahaDB store into the Active broker when it's starting up. ### The minimumReplicas Attribute -The minimumReplicas specifies how many copies of the database are required before synchronous update operations are deemed successful. Setting this to 0 allows a broker to continue operating even if there are no slaves attached. If the value is set to 1 or greater, and there are no slaves attached, the brokers persistent message processing will be suspended until the minimum number of slaves are attached and the data synchronized. +The minimumReplicas specifies how many copies of the database are required before synchronous update operations are deemed successful. Setting this to 0 allows a broker to continue operating even if there are no passive brokers attached. If the value is set to 1 or greater, and there are no passive brokers attached, the brokers persistent message processing will be suspended until the minimum number of passive brokers are attached and the data synchronized. ### The uri Attribute -The uri attribute should always be configured with a **kdbr://** based URI. KDBR stands for 'KahaDB Replication' and this is the replication protocol used between the masters and the slaves. The master binds the specified port with slaves subsequently connect to and establish replication sessions. The host name in the uri MUST get updated to the actual machine's host name since this is also used to identify the nodes in the cluster. +The uri attribute should always be configured with a **kdbr://** based URI. KDBR stands for 'KahaDB Replication' and this is the replication protocol used between the active broker and the passive brokers. The active broker binds the specified port with passive brokers subsequently connect to and establish replication sessions. The host name in the uri MUST get updated to the actual machine's host name since this is also used to identify the nodes in the cluster. ### The directory Attribute diff --git a/src/masterslave.md b/src/masterslave.md deleted file mode 100644 index 76d4f5e883..0000000000 --- a/src/masterslave.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -layout: default_md -title: MasterSlave -title-class: page-title-activemq5 -type: activemq5 ---- - - [Features](features) > [Clustering](clustering) > [MasterSlave](masterslave) - -Introduction to Master / Slave ------------------------------- - -The following are the different kinds of Master/Slave configurations available: - -Master Slave Type|Requirements|Pros|Cons ----|---|---|--- -[Shared File System Master Slave](shared-file-system-master-slave)|A shared file system such as a SAN|Run as many slaves as required. Automatic recovery of old masters|Requires shared file system -[JDBC Master Slave](jdbc-master-slave)|A Shared database|Run as many slaves as required. Automatic recovery of old masters|Requires a shared database. Also relatively slow as it cannot use the high performance journal - -If you are using a shared network file system such as a SAN we recommend a [Shared File System Master Slave](shared-file-system-master-slave). If you are happy to dispense with the high performance journal and are using pure JDBC as your persistence engine then you should use [JDBC Master Slave](jdbc-master-slave) instead. - diff --git a/src/message-groups.md b/src/message-groups.md index 19468c4901..c3c980dc91 100644 --- a/src/message-groups.md +++ b/src/message-groups.md @@ -127,7 +127,7 @@ The following code snippet shows how to wait for two consumers (or two seconds) ``` -As [the appropriate test case](https://github.com/apache/activemq/blob/master/activemq-unit-tests/src/test/java/org/apache/activemq/usecases/MessageGroupDelayedTest.java) shows, adding a small time pause before dispatching or setting a minimum consumer number, ensures equal message group distribution. +As [the appropriate test case](https://github.com/apache/activemq/blob/main/activemq-unit-tests/src/test/java/org/apache/activemq/usecases/MessageGroupDelayedTest.java) shows, adding a small time pause before dispatching or setting a minimum consumer number, ensures equal message group distribution. ### Competing demands of memory consumption, load balancing, complexity, etc. diff --git a/src/new-features-in-41.md b/src/new-features-in-41.md index 1c4b7e4024..457628510b 100644 --- a/src/new-features-in-41.md +++ b/src/new-features-in-41.md @@ -7,12 +7,13 @@ type: activemq5 [Features](features) > [New Features](new-features) > [New Features in 4.1](new-features-in-41) +{% include inclusive-terminology-notice.html %} New Features in Apache ActiveMQ 4.1 ----------------------------------- -* [Shared File System Master Slave](shared-file-system-master-slave) -* [JDBC Master Slave](jdbc-master-slave) +* [Shared File System Active Passive](shared-file-system-active-passive) +* [JDBC Active Passive](jdbc-active-passive) * [Virtual Destinations](virtual-destinations) * [Configure Startup Destinations](configure-startup-destinations) * [Structured Message Properties and MapMessages](structured-message-properties-and-mapmessages) diff --git a/src/new-features-in-52.md b/src/new-features-in-52.md index 183ab7212f..abab27f1b0 100644 --- a/src/new-features-in-52.md +++ b/src/new-features-in-52.md @@ -7,6 +7,7 @@ type: activemq5 [Features](features) > [New Features](new-features) > [New Features in 5.2](new-features-in-52) +{% include inclusive-terminology-notice.html %} Apache ActiveMQ 5.2 is primarily a maintenance release which [resolves](https://issues.apache.org/activemq/secure/ReleaseNote.jspa?projectId=10520&styleName=Html&version=11841) @@ -15,12 +16,12 @@ New Features in 5.2 The new features and enhancements in this release include: -* [Additional advisory messages](advisory-message) for messages delivered/consumed fast producers/slow consumers, Usage limits, Slaves become masters etc. +* [Additional advisory messages](advisory-message) for messages delivered/consumed fast producers/slow consumers, Usage limits, Passive brokers become the active broker etc. * Enhanced ssl context configuration through spring/xbean * New individual acknowledge mode for message consumption * Ability to configure the automatic discarding of the items being sent to the dead letter queue * Ability to limit the maximum number of connections to a Broker -* Ability to configure [separate lock](https://issues.apache.org/activemq/browse/AMQ-1244) Datasource for JDBC Master slave. +* Ability to configure [separate lock](https://issues.apache.org/activemq/browse/AMQ-1244) Datasource for JDBC Active passive. * activemq-camel and activemq-connection-pool now have their own modules, no longer in activemq-core * The default [ActiveMQConnectionFactory](http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html) brokerUrl now uses the [failover transport](failover-transport-reference). * Uses Apache Camel [1.5](http://activemq.apache.org/camel/camel-150-release.html). diff --git a/src/new-features-in-58.md b/src/new-features-in-58.md index b914d4592d..c551677fc9 100644 --- a/src/new-features-in-58.md +++ b/src/new-features-in-58.md @@ -7,11 +7,12 @@ type: activemq5 [Features](features) > [New Features](new-features) > [New Features in 5.8](new-features-in-58) +{% include inclusive-terminology-notice.html %} * [AMQP](amqp) * new feature modules and activemq-client module allowing smaller foorprint * management via [REST](rest) with [jolokia](http://www.jolokia.org/) jmx to http bridge * Includes [Apache Camel 2.10.3](http://camel.apache.org/camel-2103-release.html) * Java 7 support (compiled with jdk6 and validated with jdk7) -* [Pure Master Slave](pure-master-slave) no longer supported +* [Pure Active Passive](pure-active-passive) no longer supported diff --git a/src/new-features-in-59.md b/src/new-features-in-59.md index df3760e06b..a9740ff982 100644 --- a/src/new-features-in-59.md +++ b/src/new-features-in-59.md @@ -7,13 +7,14 @@ type: activemq5 [Features](features) > [New Features](new-features) > [New Features in 5.9](new-features-in-59) +{% include inclusive-terminology-notice.html %} -* [Replicated LevelDB Store](replicated-leveldb-store) for shared nothing Master/Slave. +* [Replicated LevelDB Store](replicated-leveldb-store) for shared nothing Active/Passive. * [Runtime Configuration](New Features in 5.9/runtime-Community/FAQ/configuration) * Generic JMS XA connection pool in activemq-jms-pool module (has no ActiveMQ dependency) * MQTT over WebSockets support * [**broker**](broker-camel-component) Apache Camel component -* Broker auto-restart upon losing master status +* Broker auto-restart upon losing active status * AMQP Hardening * LevelDB Hardening diff --git a/src/per-destination-policies.md b/src/per-destination-policies.md index 9c8d02f17f..66a15a8639 100644 --- a/src/per-destination-policies.md +++ b/src/per-destination-policies.md @@ -29,7 +29,7 @@ Common Property|Default|Description `minimumMessageSize`|`1024`|For non-serialized messages (embedded broker) - the assumed size of the message used for memory usage calculation. Serialized messages use the serialized size as the basis for the memory calculation. `prioritizedMessages`|`false`|Persist message priority information. `producerFlowControl`|`true`|If `true` the broker will throttle (flow-control) the producer. Throttling is achieved either by withholding the producer's ACK or by raising a `javax.jms.ResourceAllocationException` (that's propagated back to the client) when local resources, e.g., memory and/or storage, have been exhausted. If `false` excess messages will be written to the message store to prevent memory exhaustion. However, when the message store reaches capacity the producer will be throttled until resources are freed. -`slowConsumerStrategy`|`null`|Sets the strategy for handling slow consumers. See [AbortSlowConsumerStrategy.](https://github.com/apache/activemq/blob/master/activemq-broker/src/main/java/org/apache/activemq/broker/region/policy/AbortSlowConsumerStrategy.java) +`slowConsumerStrategy`|`null`|Sets the strategy for handling slow consumers. See [AbortSlowConsumerStrategy.](https://github.com/apache/activemq/blob/main/activemq-broker/src/main/java/org/apache/activemq/broker/region/policy/AbortSlowConsumerStrategy.java) `storeUsageHighWaterMark`|`100`|The percentage (%) threshold of the `/` store limit which when exceeded causes a producer send to block. `useCache`|`true`|If `true` persistent messages are cached for fast retrieval from store. `usePrefetchExtension` |`true`|The prefetch extension is used when a message is delivered but not ACK'ed, such that the broker can dispatch another message, e.g., `prefetch == 0`, the idea being that there will always be prefetch number of messages pending. It also allows a transaction batch to exceed the prefetch value. diff --git a/src/persistence.md b/src/persistence.md index 6a84e6dc29..cbf0e6ae4d 100644 --- a/src/persistence.md +++ b/src/persistence.md @@ -7,6 +7,8 @@ type: activemq5 [Features](features) > [Persistence](persistence) +{% include inclusive-terminology-notice.html %} + ActiveMQ V5.14.2 / V5.17.0 ------------- @@ -16,7 +18,7 @@ We once again recommend you use [KahaDB](kahadb). ActiveMQ V5.9 ------------- -In ActiveMQ 5.9, the [Replicated LevelDB Store](replicated-leveldb-store) was introduced. It handles using [Apache ZooKeeper](http://zookeeper.apache.org/) to pick a master from a set of broker nodes configured to replicate single LevelDB Store. Then synchronizes all slave LevelDB Stores with the master keeps them up to date by replicating all updates to the master. It may have become the preferred [Master Slave](masterslave) configuration going forward. +In ActiveMQ 5.9, the [Replicated LevelDB Store](replicated-leveldb-store) was introduced. It handles using [Apache ZooKeeper](http://zookeeper.apache.org/) to pick an active broker from a set of broker nodes configured to replicate single LevelDB Store. Then synchronizes all passive broker LevelDB Stores with the active broker keeps them up to date by replicating all updates to the active broker. It may have become the preferred [Active Passive](activepassive) configuration going forward. ActiveMQ V5.8 ------------- diff --git a/src/pluggable-storage-lockers.md b/src/pluggable-storage-lockers.md index efe2e53e18..49093544fc 100644 --- a/src/pluggable-storage-lockers.md +++ b/src/pluggable-storage-lockers.md @@ -7,7 +7,9 @@ type: activemq5 [Features](features) > [Persistence](persistence) > [Pluggable storage lockers](pluggable-storage-lockers) -As of the 5.7.0 release of ActiveMQ the choice of storage locking mechanism, as used by a persistence adapter, has been made pluggable. This feature is only meaningful to brokers configured in a shared storage master/slave topology. Prior to release 5.7.0 the storage locking mechanism (and thus master election) was dictated by the choice of persistence adapter. With the KahaDB persistence adapter, for example, the storage locking mechanism was based on a shared file lock. Similarly, the JDBC persistence adapter used a database backed storage lock. +{% include inclusive-terminology-notice.html %} + +As of the 5.7.0 release of ActiveMQ the choice of storage locking mechanism, as used by a persistence adapter, has been made pluggable. This feature is only meaningful to brokers configured in a shared storage active/passive topology. Prior to release 5.7.0 the storage locking mechanism (and thus active broker election) was dictated by the choice of persistence adapter. With the KahaDB persistence adapter, for example, the storage locking mechanism was based on a shared file lock. Similarly, the JDBC persistence adapter used a database backed storage lock. Now that the choice of storage locker is divorced from that of the persistence adapter one can mix and match combinations of the two. Storage locker pluggability is made possible by the [Locker](https://fisheye6.atlassian.com/browse/activemq/trunk/activemq-broker/src/main/java/org/apache/activemq/broker/Locker.java?hb=true) interface that all pluggable lockers must implement. This interface makes it easy to implement a custom storage locker that meets local requirements. @@ -21,7 +23,7 @@ Every locker must implement the [Locker](https://fisheye6.atlassian.com/browse/a Property Name|Default Value|Description ---|---|--- `lockAcquireSleepInterval`|`10000`|The polling interval (in milliseconds) between lock acquire attempts. -`failIfLocked`|`false`|Should the broker start fail if the lock is not immediately available. When `true` slave brokers will not start. +`failIfLocked`|`false`|Should the broker start fail if the lock is not immediately available. When `true` passive brokers will not start. Persistence Adapters -------------------- @@ -39,7 +41,7 @@ Existing Lockers ### Shared File Locker -The Shared File Locker is the default locker for the KahaDB persistence adapter. It locks a file to ensure that only the broker holding the lock (the master) is granted access to the message store. +The Shared File Locker is the default locker for the KahaDB persistence adapter. It locks a file to ensure that only the broker holding the lock (the active broker) is granted access to the message store. #### Example: ``` @@ -56,11 +58,11 @@ The `lockKeepAlivePeriod` attribute is not applicable to versions of ActiveMQ o > Consequences of lockKeepAlivePeriod = 0 > -> For this locker `lockKeepAlivePeriod` should be greater than `0`.This period is the frequency with which the master broker makes lock keep alive calls. +> For this locker `lockKeepAlivePeriod` should be greater than `0`.This period is the frequency with which the active broker makes lock keep alive calls. > -> When `lockKeepAlivePeriod = 0` slave brokers are still unable to obtain the file lock. However, if some third party modifies the lock file (either modification or deletion) the master broker will not detect the change. Therefore a slave broker's next attempt (per its configured `lockAcquireSleepInterval`) to obtain the file lock will succeed. When this happens there will be two master brokers in the cluster. _This situation will result in message store corruption_! +> When `lockKeepAlivePeriod = 0` passive brokers are still unable to obtain the file lock. However, if some third party modifies the lock file (either modification or deletion) the active broker will not detect the change. Therefore a passive broker's next attempt (per its configured `lockAcquireSleepInterval`) to obtain the file lock will succeed. When this happens there will be two active brokers in the cluster. _This situation will result in message store corruption_! > -> When `lockKeepAlivePeriod` is greater than `0`, the master broker will make a lock keep alive call every `lockKeepAlivePeriod` milliseconds. Therefore the master broker will detect any lock file changes when it makes its next keep alive call. Upon detecting said change the master broker will demote itself to a slave broker. +> When `lockKeepAlivePeriod` is greater than `0`, the active broker will make a lock keep alive call every `lockKeepAlivePeriod` milliseconds. Therefore the active broker will detect any lock file changes when it makes its next keep alive call. Upon detecting said change the active broker will demote itself to a passive broker. > Note that as of ActiveMQ 5.9.0 the KahaDB persistence adapter can also use the Lease Database Locker (see below). @@ -83,11 +85,11 @@ The Database Locker uses its `keepAlive` method to ensure the broker still hold This locker opens a JDBC transaction against a database table (`activemq_lock`) that lasts as long as the broker remains alive. This locks the entire table and prevents another broker from accessing the store. In most cases this will be a fairly long running JDBC transaction which occupies resources on the database over time. -A problem with this locker can arise when the master broker crashes or loses its connection to the database causing the lock to remain in the database until the database responds to the half closed socket connection via a TCP timeout. The database lock expiry requirement can prevent the slave from starting some time. In addition, if the database supports failover, and the connection is dropped in the event of a replica failover, that JDBC transaction will be rolled back. The broker sees this as a failure. Both master and slave brokes will again compete for a lock. +A problem with this locker can arise when the active broker crashes or loses its connection to the database causing the lock to remain in the database until the database responds to the half closed socket connection via a TCP timeout. The database lock expiry requirement can prevent the passive broker from starting some time. In addition, if the database supports failover, and the connection is dropped in the event of a replica failover, that JDBC transaction will be rolled back. The broker sees this as a failure. Both active and passive brokes will again compete for a lock. ### Lease Database Locker -The Lease Database Locker was created to solve the shortcomings of the Database Locker. The Lease Database Locker does not open a long running JDBC transaction. Instead it lets the master broker acquire a lock that's valid for a fixed (usually short) duration after which it expires. To retain the lock the master broker must periodically extend the lock's lease before it expires. Simultaneously the slave broker checks periodically to see if the lease has expired. If, for whatever reason, the master broker fails to update its lease on the lock the slave will take ownership of the lock becoming the new master in the process. The leased lock can survive a DB replica failover. +The Lease Database Locker was created to solve the shortcomings of the Database Locker. The Lease Database Locker does not open a long running JDBC transaction. Instead it lets the active broker acquire a lock that's valid for a fixed (usually short) duration after which it expires. To retain the lock the active broker must periodically extend the lock's lease before it expires. Simultaneously the passive broker checks periodically to see if the lease has expired. If, for whatever reason, the active broker fails to update its lease on the lock the passive broker will take ownership of the lock becoming the new active broker in the process. The leased lock can survive a DB replica failover. #### Example: ``` @@ -100,11 +102,11 @@ The Lease Database Locker was created to solve the shortcomings of the Database ``` -In order for this mechanism to work correctly, each broker in a master/slave(s) cluster must have a unique value for the `brokerName` attribute as defined on the `` tag. Alternatively, use unique values for the `leaseHolderId` attribute on the `` tag as this value is used to create a lease lock definition. +In order for this mechanism to work correctly, each broker in a active/passive(s) cluster must have a unique value for the `brokerName` attribute as defined on the `` tag. Alternatively, use unique values for the `leaseHolderId` attribute on the `` tag as this value is used to create a lease lock definition. -The lease based lock is acquired by blocking at startup. It is then retained for a period whose duration (in ms) is given by the `lockKeepAlivePeriod` attribute. To retain the lock the master broker periodically extends its lease by `lockAcquireSleepInterval` milliseconds each time. In theory, therefore, the master broker is always (`lockAcquireSleepInterval - lockKeepAlivePeriod`) ahead of the slave broker with regard to the lease. It is imperative that `lockAcquireSleepInterval > lockKeepAlivePeriod`, to ensure the lease is always current. As of ActiveMQ 5.9.0 a warning message is logged if this condition is not met. +The lease based lock is acquired by blocking at startup. It is then retained for a period whose duration (in ms) is given by the `lockKeepAlivePeriod` attribute. To retain the lock the active broker periodically extends its lease by `lockAcquireSleepInterval` milliseconds each time. In theory, therefore, the active broker is always (`lockAcquireSleepInterval - lockKeepAlivePeriod`) ahead of the passive broker with regard to the lease. It is imperative that `lockAcquireSleepInterval > lockKeepAlivePeriod`, to ensure the lease is always current. As of ActiveMQ 5.9.0 a warning message is logged if this condition is not met. -In the simplest case, the clocks between master and slave must be in sync for this solution to work properly. If the clocks cannot be in sync, the locker can use the system time from the database CURRENT TIME and adjust the timeouts in accordance with their local variance from the DB system time. If `maxAllowableDiffFromDBTime` is greater than zero the local periods will be adjusted by any delta that exceeds `maxAllowableDiffFromDBTime`. +In the simplest case, the clocks between active and passive brokers must be in sync for this solution to work properly. If the clocks cannot be in sync, the locker can use the system time from the database CURRENT TIME and adjust the timeouts in accordance with their local variance from the DB system time. If `maxAllowableDiffFromDBTime` is greater than zero the local periods will be adjusted by any delta that exceeds `maxAllowableDiffFromDBTime`. > It is important to know if the default rules your JDBC driver uses for converting `TIME` values are JDBC compliant. If you're using MySQL, for example, the driver's JDBC URL should contain `useJDBCCompliantTimezoneShift=true` to ensure that `TIME` value conversion is JDBC compliant. If not the locker could report a large time difference when it compares the retrieved lease expiration time against the current system time. Consult your JDBC driver's documentation for more details. diff --git a/src/pure-active-passive.md b/src/pure-active-passive.md new file mode 100644 index 0000000000..59ba83b8c9 --- /dev/null +++ b/src/pure-active-passive.md @@ -0,0 +1,98 @@ +--- +layout: default_md +title: Pure Active Passive +title-class: page-title-activemq5 +type: activemq5 +redirect_from: +- /pure-master-slave +--- + +[Features](features) > [Clustering](clustering) > [ActivePassive](activepassive) > [Pure Active Passive](pure-active-passive) + +{% include inclusive-terminology-notice.html %} + +> **Warning** +> +> The LevelDB store has been removed from production. +> This page only serves as an archival page for previous releases. +> Use [shared storage active/passive](activepassive) instead. + + +### Pure Active Passive + +> This feature has been deprecated and will be removed in version 5.8 +> +> This feature will be removed in 5.8 as it has not evolved to be production ready. You are advised to use [shared storage active/passive](activepassive) or the [Replicated LevelDB Store](replicated-leveldb-store). See [AMQ-4165](https://issues.apache.org/jira/browse/AMQ-4165) + +A Pure Active Passive configuration provides a basic shared nothing, fully replicated topology which does not depend on a shared file system or shared database. + +### How Pure Active Passive works + +* A passive of a active broker consumes all message states from the active - messages, acknowledgments and transactional states. + Whilst a Passive is actively connected to the Active - it does not allow or start any network or transport connectors, it's sole purpose is to duplicate the state of the active. + +* The active broker will only respond to a client when a message exchange has been successfully passed to the passive. For example, a commit + in a clients transaction will not complete until the active and the passive have processed the commit. + +* In the event the active fails (e.g. hardware failure) the passive has optionally two modes of operation + 1. starts all it's network and transport connectors - allowing clients connected to the active to resume on the passive. + 2. or can be configured to close down. In this mode, the passive is simply used to duplicate state for the active. + +* clients should use a failover transport for connecting to the active broker first and then the passive. e.g. using a URL such as +``` +failover://(tcp://activehost:61616,tcp://passivehost:61616)?randomize=false +``` +The **randomize** property just disables randomness so that the transport will always try the active first, then the passive if it can't connect to that. Note that the passive does not accept connections until it becomes the active + +### Limitations of Pure Active Passive + +* Only one passive can be connected to the Active +* A failed active cannot be re-introduced without shutting down the the passive broker (no automatic failback) +* There is no automatic synchronization between brokers. This is a manual process. + +### Recovering a Pure Active Passive topology + +This is a manual process - once a active has failed, the only sure way to ensure that the toplogy is synchronized again is manually: + +* shutdown the passive broker (The clients do not need to be shutdown - they will wait until the topology is re-established if they are failover clients +* copy the data directory from the passive over the data directory of the active broker +* re-start the active and the passive + +### Configuring Pure Active Passive + +You should not configure a connection between the active and a passive. The connection is automatically established with the passive's configuration. If you explicitly configure a network connection, you may encounter race conditions when the active broker is under heavy load. + +A active broker doesn't need any special configuration - it's a normal broker until a passive broker attaches itself. +To identify a broker as a passive - there is just one property to set (see below) as this [example shows](http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/test/resources/org/apache/activemq/broker/ft/passive2.xml) - so configuration is nice and easy: +``` + + + + + + + + + +``` +Broker Property|default|Description +---|---|--- +activeConnectorURI|null|URI to the active broker e.g. `tcp://activehost:62001` +shutdownOnMasterFailure|false|if true, the passive will shut down if the active fails otherwise the passive will take over as being the new active. The passive ensures that there is a separate copy of each message and acknowledgement on another machine which can protect against catastrophic hardware failure. If the active fails you might want the passive to shut down as well as you may always want to duplicate messages to 2 physical locations to prevent message loss on catastrophic data centre or hardware failure. If you would rather the system keep on running after a active failure then leave this flag as false. +waitForPassive|false|version 5.2+, if true, a active will wait till a passive has attached before completing its startup sequence +shutdownOnPassiveFailure|false|version 5.2+, if true, a active will shutdown if the passive connection is lost, ensuring that the active will not become out of sync with the passive. + +### Configuring the authentication of the Passive + +In ActiveMQ 4.1 or later you can use a `` element as an alternative XML configuration mechanism as shown in the following [example](http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/test/resources/org/apache/activemq/broker/ft/slave2.xml) to configure the user and password that the passive will use to connect to the active +``` + + + + + + + + + +``` diff --git a/src/pure-master-slave.md b/src/pure-master-slave.md deleted file mode 100644 index cd2d32ae56..0000000000 --- a/src/pure-master-slave.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -layout: default_md -title: Pure Master Slave -title-class: page-title-activemq5 -type: activemq5 ---- - -[Features](features) > [Clustering](clustering) > [MasterSlave](masterslave) > [Pure Master Slave](pure-master-slave) - -> **Warning** -> -> The LevelDB store has been removed from production. -> This page only serves as an archival page for previous releases. -> Use [shared storage master/slave](masterslave) instead. - - -### Pure Master Slave - -> This feature has been deprecated and will be removed in version 5.8 -> -> This feature will be removed in 5.8 as it has not evolved to be production ready. You are advised to use [shared storage master/slave](masterslave) or the [Replicated LevelDB Store](replicated-leveldb-store). See [AMQ-4165](https://issues.apache.org/jira/browse/AMQ-4165) - -A Pure Master Slave configuration provides a basic shared nothing, fully replicated topology which does not depend on a shared file system or shared database. - -### How Pure Master Slave works - -* A slave of a master broker consumes all message states from the master - messages, acknowledgments and transactional states. - Whilst a Slave is actively connected to the Master - it does not allow or start any network or transport connectors, it's sole purpose is to duplicate the state of the master. - -* The master broker will only respond to a client when a message exchange has been successfully passed to the slave. For example, a commit - in a clients transaction will not complete until the master and the slave have processed the commit. - -* In the event the master fails (e.g. hardware failure) the slave has optionally two modes of operation - 1. starts all it's network and transport connectors - allowing clients connected to the master to resume on the slave. - 2. or can be configured to close down. In this mode, the slave is simply used to duplicate state for the master. - -* clients should use a failover transport for connecting to the master broker first and then the slave. e.g. using a URL such as -``` -failover://(tcp://masterhost:61616,tcp://slavehost:61616)?randomize=false -``` -The **randomize** property just disables randomness so that the transport will always try the master first, then the slave if it can't connect to that. Note that the slave does not accept connections until it becomes the master - -### Limitations of Pure Master Slave - -* Only one slave can be connected to the Master -* A failed master cannot be re-introduced without shutting down the the slave broker (no automatic failback) -* There is no automatic synchronization between brokers. This is a manual process. - -### Recovering a Pure Master Slave topology - -This is a manual process - once a master has failed, the only sure way to ensure that the toplogy is synchronized again is manually: - -* shutdown the slave broker (The clients do not need to be shutdown - they will wait until the topology is re-established if they are failover clients -* copy the data directory from the slave over the data directory of the master broker -* re-start the master and the slave - -### Configuring Pure Master Slave - -You should not configure a connection between the master and a slave. The connection is automatically established with the slave's configuration. If you explicitly configure a network connection, you may encounter race conditions when the master broker is under heavy load. - -A master broker doesn't need any special configuration - it's a normal broker until a slave broker attaches itself. -To identify a broker as a slave - there is just one property to set (see below) as this [example shows](http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/test/resources/org/apache/activemq/broker/ft/slave2.xml) - so configuration is nice and easy: -``` - - - - - - - - - -``` -Broker Property|default|Description ----|---|--- -masterConnectorURI|null|URI to the master broker e.g. `tcp://masterhost:62001` -shutdownOnMasterFailure|false|if true, the slave will shut down if the master fails otherwise the slave will take over as being the new master. The slave ensures that there is a separate copy of each message and acknowledgement on another machine which can protect against catastrophic hardware failure. If the master fails you might want the slave to shut down as well as you may always want to duplicate messages to 2 physical locations to prevent message loss on catastrophic data centre or hardware failure. If you would rather the system keep on running after a master failure then leave this flag as false. -waitForSlave|false|version 5.2+, if true, a master will wait till a slave has attached before completing its startup sequence -shutdownOnSlaveFailure|false|version 5.2+, if true, a master will shutdown if the slave connection is lost, ensuring that the master will not become out of sync with the slave. - -### Configuring the authentication of the Slave - -In ActiveMQ 4.1 or later you can use a `` element as an alternative XML configuration mechanism as shown in the following [example](http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/test/resources/org/apache/activemq/broker/ft/slave2.xml) to configure the user and password that the slave will use to connect to the master -``` - - - - - - - - - -``` diff --git a/src/replicated-leveldb-store.md b/src/replicated-leveldb-store.md index 567ce9e6e1..fea3937e2b 100644 --- a/src/replicated-leveldb-store.md +++ b/src/replicated-leveldb-store.md @@ -4,6 +4,7 @@ title: Replicated LevelDB Store title-class: page-title-activemq5 type: activemq5 --- +{% include inclusive-terminology-notice.html %} > **Warning** > @@ -12,7 +13,7 @@ type: activemq5 Synopsis -------- -The Replicated LevelDB Store uses Apache ZooKeeper to pick a master from a set of broker nodes configured to replicate a LevelDB Store. Then synchronizes all slave LevelDB Stores with the master keeps them up to date by replicating all updates from the master. +The Replicated LevelDB Store uses Apache ZooKeeper to pick an active broker from a set of broker nodes configured to replicate a LevelDB Store. Then synchronizes all passive broker LevelDB Stores with the active broker keeps them up to date by replicating all updates from the active broker. The Replicated LevelDB Store uses the same data files as a LevelDB Store, so you can switch a broker configuration between replicated and non replicated whenever you want. @@ -25,11 +26,11 @@ How it works. ![](assets/img/replicated-leveldb-store.png) -It uses [Apache ZooKeeper](http://zookeeper.apache.org/) to coordinate which node in the cluster becomes the master. The elected master broker node starts and accepts client connections. The other nodes go into slave mode and connect the the master and synchronize their persistent state /w it. The slave nodes do not accept client connections. All persistent operations are replicated to the connected slaves. If the master dies, the slaves with the latest update gets promoted to become the master. The failed node can then be brought back online and it will go into slave mode. +It uses [Apache ZooKeeper](http://zookeeper.apache.org/) to coordinate which node in the cluster becomes the active broker. The elected active broker node starts and accepts client connections. The other nodes go into passive broker mode and connect to the active broker and synchronize their persistent state /w it. The passive brokers do not accept client connections. All persistent operations are replicated to the connected passive brokers. If the active broker dies, the passive brokers with the latest update gets promoted to become the active broker. The failed node can then be brought back online and it will go into passive broker mode. -All messaging operations which require a sync to disk will wait for the update to be replicated to a quorum of the nodes before completing. So if you configure the store with `replicas="3"` then the quorum size is `(3/2+1)=2`. The master will store the update locally and wait for 1 other slave to store the update before reporting success. Another way to think about it is that store will do synchronous replication to a quorum of the replication nodes and asynchronous replication replication to any additional nodes. +All messaging operations which require a sync to disk will wait for the update to be replicated to a quorum of the nodes before completing. So if you configure the store with `replicas="3"` then the quorum size is `(3/2+1)=2`. The active broker will store the update locally and wait for 1 other passive broker to store the update before reporting success. Another way to think about it is that store will do synchronous replication to a quorum of the replication nodes and asynchronous replication replication to any additional nodes. -When a new master is elected, you also need at least a quorum of nodes online to be able to find a node with the lastest updates. The node with the lastest updates will become the new master. Therefore, it's recommend that you run with at least 3 replica nodes so that you can take one down without suffering a service outage. +When a new active broker is elected, you also need at least a quorum of nodes online to be able to find a node with the lastest updates. The node with the lastest updates will become the new active broker. Therefore, it's recommend that you run with at least 3 replica nodes so that you can take one down without suffering a service outage. ### Deployment Tips @@ -39,7 +40,7 @@ failover:(tcp://broker1:61616,tcp://broker2:61616,tcp://broker3:61616) ``` You should run at least 3 ZooKeeper server nodes so that the ZooKeeper service is highly available. Don't overcommit your ZooKeeper servers. An overworked ZooKeeper might start thinking live replication nodes have gone offline due to delays in processing their 'keep-alive' messages. -For best results, make sure you explicitly configure the hostname attribute with a hostname or ip address for the node that other cluster members to access the machine with. The automatically determined hostname is not always accessible by the other cluster members and results in slaves not being able to establish a replication session with the master. +For best results, make sure you explicitly configure the hostname attribute with a hostname or ip address for the node that other cluster members to access the machine with. The automatically determined hostname is not always accessible by the other cluster members and results in passive brokers not being able to establish a replication session with the active broker. Configuration ------------- @@ -73,7 +74,7 @@ property name|default value|Comments `securityToken`||A security token which must match on all replication nodes for them to accept each others replication requests. `zkAddress`|`127.0.0.1:2181`|A comma separated list of ZooKeeper servers. `zkPassword`||The password to use when connecting to the ZooKeeper server. -`zkPath`|`/default`|The path to the ZooKeeper directory where Master/Slave election information will be exchanged. +`zkPath`|`/default`|The path to the ZooKeeper directory where Active/Passive election information will be exchanged. `zkSessionTimeout`|`2s`|How quickly a node failure will be detected by ZooKeeper. (prior to 5.11 - this had a typo zkSessionTmeout) `sync`|`quorum_mem`|Controls where updates are reside before being considered complete. This setting is a comma separated list of the following options: `local_mem`, `local_disk`, `remote_mem`, `remote_disk`, `quorum_mem`, `quorum_disk`. If you combine two settings for a target, the stronger guarantee is used. For example, configuring `local_mem, local_disk` is the same as just using `local_disk`. quorum_mem is the same as `local_mem, remote_mem` and `quorum_disk` is the same as `local_disk, remote_disk` @@ -83,9 +84,9 @@ The following configuration properties can be unique per node: property name||default value|Comments ---|---|--- -`bind`|`tcp://0.0.0.0:61619`|When this node becomes a master, it will bind the configured address and port to service the replication protocol. Using dynamic ports is also supported. Just configure with `tcp://0.0.0.0:0` -`hostname`||The host name used to advertise the replication service when this node becomes the master. If not set it will be automatically determined.| -`weight`|`1`|The replication node that has the latest update with the highest weight will become the master. Used to give preference to some nodes towards becoming master. +`bind`|`tcp://0.0.0.0:61619`|When this node becomes the active broker, it will bind the configured address and port to service the replication protocol. Using dynamic ports is also supported. Just configure with `tcp://0.0.0.0:0` +`hostname`||The host name used to advertise the replication service when this node becomes the active broker. If not set it will be automatically determined.| +`weight`|`1`|The replication node that has the latest update with the highest weight will become the active broker. Used to give preference to some nodes towards becoming active broker. The store also supports the same configuration properties of a standard [LevelDB Store](leveldb-store) but it does not support the pluggable storage lockers : @@ -109,5 +110,5 @@ property name|default value|Comments > **Caveats** > -> The LevelDB store does not yet support storing data associated with [Delay and Schedule Message Delivery](delay-and-schedule-message-delivery). Those are are stored in a separate non-replicated KahaDB data files. Unexpected results will occur if you use [Delay and Schedule Message Delivery](delay-and-schedule-message-delivery) with the replicated leveldb store since that data will be not be there when the master fails over to a slave. +> The LevelDB store does not yet support storing data associated with [Delay and Schedule Message Delivery](delay-and-schedule-message-delivery). Those are are stored in a separate non-replicated KahaDB data files. Unexpected results will occur if you use [Delay and Schedule Message Delivery](delay-and-schedule-message-delivery) with the replicated leveldb store since that data will be not there when the active broker fails over to a passive broker. diff --git a/src/replicated-message-store.md b/src/replicated-message-store.md index 7c1aeb2e3d..f2f77ed499 100644 --- a/src/replicated-message-store.md +++ b/src/replicated-message-store.md @@ -7,6 +7,7 @@ type: activemq5 [Features](features) > [Clustering](clustering) > [Replicated Message Store](replicated-message-store) +{% include inclusive-terminology-notice.html %} If messages are stored on the hard drive of a broker or inside a single database; then you have a single point of failure with respect to the message persistence. If you lose the entire machine, disk or database, you have lost messages. @@ -22,11 +23,11 @@ If you're using RAID disks striped sufficiently, you could just restart the mach If you use one of the file based persistence mechanisms such as the default high performance journal and Apache Derby, you could write to a SAN or shared network drive and in times of failure, start up a new broker using the files from the failed broker. -Also 4.1 allows you to start many brokers reading from the same shared file system to support high availability via the [Shared File System Master Slave](shared-file-system-master-slave) feature. +Also 4.1 allows you to start many brokers reading from the same shared file system to support high availability via the [Shared File System Active Passive](shared-file-system-active-passive) feature. -### Master/Slave +### Active/Passive -An alternative is to use the [MasterSlave](masterslave) feature to pair brokers together so that all messages are replicated to both brokers, the master and slave to ensure that there are two physical copies of the message so that catastrophic hardware failures (such as loss of an entire data centre) can be handled. +An alternative is to use the [ActivePassive](activepassive) feature to pair brokers together so that all messages are replicated to both brokers, the active and passive to ensure that there are two physical copies of the message so that catastrophic hardware failures (such as loss of an entire data centre) can be handled. ### Clustered JDBC databases diff --git a/src/rest.md b/src/rest.md index 30b3964cf4..69d60c59b1 100644 --- a/src/rest.md +++ b/src/rest.md @@ -205,7 +205,7 @@ or to be more specific, total consumer count with ``` wget --user admin --password admin --header "Origin: http://localhost" --auth-no-challenge http://localhost:8161/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=localhost/TotalConsumerCount ``` -By default, ActiveMQ uses the [following](https://github.com/apache/activemq/blob/master/assembly/src/release/webapps/api/WEB-INF/classes/jolokia-access.xml) Jolokia security policy: +By default, ActiveMQ uses the [following](https://github.com/apache/activemq/blob/main/assembly/src/release/webapps/api/WEB-INF/classes/jolokia-access.xml) Jolokia security policy: ``` diff --git a/src/shared-file-system-master-slave.md b/src/shared-file-system-active-passive.md similarity index 58% rename from src/shared-file-system-master-slave.md rename to src/shared-file-system-active-passive.md index 79101c0465..241a07653e 100644 --- a/src/shared-file-system-master-slave.md +++ b/src/shared-file-system-active-passive.md @@ -1,24 +1,28 @@ --- layout: default_md -title: Shared File System Master Slave +title: Shared File System Active Passive title-class: page-title-activemq5 type: activemq5 +redirect_from: +- /shared-file-system-master-slave --- -[Features](features) > [Clustering](clustering) > [MasterSlave](masterslave) > [Shared File System Master Slave](shared-file-system-master-slave) +[Features](features) > [Clustering](clustering) > [ActivePassive](activepassive) > [Shared File System Active Passive](shared-file-system-active-passive) -Shared File System Master Slave +{% include inclusive-terminology-notice.html %} + +Shared File System Active Passive ------------------------------- If you have a SAN or shared file system it can be used to provide _high availability_ such that if a broker is killed, another broker can take over immediately. > Ensure your shared file locks work > -> Note that the requirements of this failover system are a distributed file system like a SAN for which exclusive file locks work reliably. If you do not have such a thing available then consider using [MasterSlave](masterslave) instead which implements something similar but working on commodity hardware using local file systems which ActiveMQ does the replication. +> Note that the requirements of this failover system are a distributed file system like a SAN for which exclusive file locks work reliably. If you do not have such a thing available then consider using [ActivePassive](activepassive) instead which implements something similar but working on commodity hardware using local file systems which ActiveMQ does the replication. > > > **OCFS2 Warning** > > -> > Was testing using OCFS2 and both brokers thought they had the master lock - this is because "OCFS2 only supports locking with 'fcntl' and not 'lockf and flock', therefore mutex file locking from Java isn't supported." +> > Was testing using OCFS2 and both brokers thought they had the active lock - this is because "OCFS2 only supports locking with 'fcntl' and not 'lockf and flock', therefore mutex file locking from Java isn't supported." > > > > From [http://sources.redhat.com/cluster/faq.html#gfs_vs_ocfs2](http://sources.redhat.com/cluster/faq.html#gfs_vs_ocfs2) : > > OCFS2: No cluster-aware flock or POSIX locks @@ -27,13 +31,13 @@ If you have a SAN or shared file system it can be used to provide _high availabi > > > **NFSv3 Warning** > > -> > In the event of an abnormal NFSv3 client termination (i.e., the ActiveMQ master broker), the NFSv3 server will not timeout the lock that is held by that client. This effectively renders the ActiveMQ data directory inaccessible because the ActiveMQ slave broker can't acquire the lock and therefore cannot start up. The only solution to this predicament with NFSv3 is to reboot all ActiveMQ instances to reset everything. +> > In the event of an abnormal NFSv3 client termination (i.e., the ActiveMQ active broker), the NFSv3 server will not timeout the lock that is held by that client. This effectively renders the ActiveMQ data directory inaccessible because the ActiveMQ passive broker can't acquire the lock and therefore cannot start up. The only solution to this predicament with NFSv3 is to reboot all ActiveMQ instances to reset everything. > > > > Use of NFSv4 is another solution because its design includes timeouts for locks. When using NFSv4 and the client holding the lock experiences an abnormal termination, by design, the lock is released after 30 seconds, allowing another client to grab the lock. For more information about this, see [this blog entry](http://blogs.netapp.com/eislers_nfs_blog/2008/07/part-i-since-nf.html). -Basically you can run as many brokers as you wish from the same shared file system directory. The first broker to grab the exclusive lock on the file is the master broker. If that broker dies and releases the lock then another broker takes over. The slave brokers sit in a loop trying to grab the lock from the master broker. +Basically you can run as many brokers as you wish from the same shared file system directory. The first broker to grab the exclusive lock on the file is the active broker. If that broker dies and releases the lock then another broker takes over. The passive brokers sit in a loop trying to grab the lock from the active broker. -The following example shows how to configure a broker for Shared File System Master Slave where **/sharedFileSystem** is some directory on a shared file system. It is just a case of configuring a file based store to use a shared directory. +The following example shows how to configure a broker for Shared File System Active Passive where **/sharedFileSystem** is some directory on a shared file system. It is just a case of configuring a file based store to use a shared directory. ``` @@ -53,7 +57,7 @@ or: ``` ### Startup -On startup one master grabs an exclusive lock on the broker file directory - all other brokers are slaves and pause waiting for the exclusive lock. +On startup one active grabs an exclusive lock on the broker file directory - all other brokers are passives and pause waiting for the exclusive lock. ![](assets/img/Startup.png) @@ -61,23 +65,23 @@ Clients should be using the [Failover Transport](failover-transport-reference) t ``` failover:(tcp://broker1:61616,tcp://broker2:61616,tcp://broker3:61616) ``` -Only the master broker starts up its transport connectors and so the clients can only connect to the master. +Only the active broker starts up its transport connectors and so the clients can only connect to the active. -### Master failure +### Active failure -If the master looses the exclusive lock then it immediately shuts down. If a master shuts down or fails, one of the other slaves will grab the lock and so the topology switches to the following diagram +If the active looses the exclusive lock then it immediately shuts down. If a active shuts down or fails, one of the other passives will grab the lock and so the topology switches to the following diagram -![](assets/img/MasterFailed.png) +![](assets/img/ActiveFailed.png) -One of the other other slaves immediately grabs the exclusive lock on the file system to them commences becoming the master, starting all of its transport connectors. +One of the other other passives immediately grabs the exclusive lock on the file system to them commences becoming the active, starting all of its transport connectors. -Clients loose connection to the stopped master and then the failover transport tries to connect to the available brokers - of which the only one available is the new master. +Clients loose connection to the stopped active and then the failover transport tries to connect to the available brokers - of which the only one available is the new active. -### Master restart +### Active restart -At any time you can restart other brokers which join the cluster and start as slaves waiting to become a master if the master is shutdown or a failure occurs. So the following topology is created after a restart of an old master... +At any time you can restart other brokers which join the cluster and start as passives waiting to become a active if the active is shutdown or a failure occurs. So the following topology is created after a restart of an old active... -![](assets/img/MasterRestarted.png) +![](assets/img/ActiveRestarted.png) ### Scheduler Support diff --git a/src/sitemap.md b/src/sitemap.md index c7d63b918b..675c5c03ee 100644 --- a/src/sitemap.md +++ b/src/sitemap.md @@ -7,6 +7,7 @@ type: activemq5 [Site](site) > [SiteMap](sitemap) +{% include inclusive-terminology-notice.html %} Using ActiveMQ -------------- @@ -325,10 +326,10 @@ Features * [The ActiveBlaze Message type](the-activeblaze-message-type) * [Broker Camel Component](broker-camel-component) * [Clustering]() - * [MasterSlave]() - * [JDBC Master Slave](jdbc-master-slave) + * [ActivePassive]() + * [JDBC Active Passive](jdbc-active-passive) * [KahaDB Replication (Experimental)](kahadb-replication-experimental) - * [Shared File System Master Slave](shared-file-system-master-slave) + * [Shared File System Active Passive](shared-file-system-active-passive) * [Networks of Brokers](networks-of-brokers) * [Replicated Message Store](replicated-message-store) * [Command Agent](command-agent) diff --git a/src/source.md b/src/source.md index e8c34f2e46..ef9abf5021 100644 --- a/src/source.md +++ b/src/source.md @@ -46,12 +46,12 @@ Checking out from the Github Repo git clone [https://github.com/apache/activemq-artemis](https://github.com/apache/activemq-artemis) -**Committers:** Please follow the instructions for properly configuring the [Instructions for Core Contributors/Hacking Guide](https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/enSUMMARY) +**Committers:** Please follow the instructions for properly configuring the [Instructions for Core Contributors/Hacking Guide](https://github.com/apache/activemq-artemis/blob/main/docs/hacking-guide/enSUMMARY) **Contributors:** Please create a [pull request](https://github.com/apache/activemq-artemis) to contribute changes to the source code.  Building the code ----------------- -To then build the code, take a look at [Building the distribution](https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/enDevelopers/Developers/building) +To then build the code, take a look at [Building the distribution](https://github.com/apache/activemq-artemis/blob/main/docs/hacking-guide/enDevelopers/Developers/building) diff --git a/src/svn.md b/src/svn.md index 363b845d13..eb9371db1c 100644 --- a/src/svn.md +++ b/src/svn.md @@ -50,12 +50,12 @@ Checking out from the Github Repo git clone [https://github.com/apache/activemq-artemis](https://github.com/apache/activemq-artemis) -`Committers:** Please follow the instructions for properly configuring the [Instructions for Core Contributors/Hacking Guide](https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/enSUMMARY) +`Committers:** Please follow the instructions for properly configuring the [Instructions for Core Contributors/Hacking Guide](https://github.com/apache/activemq-artemis/blob/main/docs/hacking-guide/enSUMMARY) `Contributors:** Please create a [pull request](https://github.com/apache/activemq-artemis) to contribute changes to the source code.  Building the code ----------------- -To then build the code, take a look at [Building the distribution](https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/enDevelopers/Developers/building) +To then build the code, take a look at [Building the distribution](https://github.com/apache/activemq-artemis/blob/main/docs/hacking-guide/enDevelopers/Developers/building) diff --git a/src/sybase.md b/src/sybase.md index a4a756de41..f3d67e030a 100644 --- a/src/sybase.md +++ b/src/sybase.md @@ -7,6 +7,7 @@ type: activemq5 [Features](features) > [Persistence](persistence) > [JDBC Support](jdbc-support) > [Sybase](Persistence/JDBC Support/sybase) +{% include inclusive-terminology-notice.html %} Sybase ------ @@ -29,7 +30,7 @@ A dataSource targetting a Sybase ASE database can be configured as follows: -When working on a given Sybase ASE database, each operation (e.g. statement execution) is appended to the transaction log. This log grows over time, and space has to be freed in order to let the server keep running. ASE is able to free space up to the oldest opened transaction; that is, if you keep a transaction open for too long, the transaction log only grows - until the allocated space is full and the database goes down. So when using the Master-Slave feature of ActiveMQ with a database lock on table ACTIVEMQ_LOCK a synchronization monitor (see [http://activemq.apache.orgFeatures/Clustering/MasterSlaveFeatures/Clustering/MasterSlave/Features/Clustering/MasterSlave/jdbc-master-slave.md](http://activemq.apache.orgFeatures/Clustering/MasterSlaveFeatures/Clustering/MasterSlave/Features/Clustering/MasterSlave/jdbc-master-slave)), you have to be careful. If you use only one dataSource, hence only one database, then the lock mechanism shall keep a transaction indefinitely open, and while messages are persisted the transaction log shall grow until you run out of space. It is therefore strongly advised to use a dedicated database for this lock: just define another dataSource targeting a minimal database holding no data (only the ACTIVEMQ_LOCK table) and use it as a lockDataSource in your configuration. +When working on a given Sybase ASE database, each operation (e.g. statement execution) is appended to the transaction log. This log grows over time, and space has to be freed in order to let the server keep running. ASE is able to free space up to the oldest opened transaction; that is, if you keep a transaction open for too long, the transaction log only grows - until the allocated space is full and the database goes down. So when using the Active-Passive feature of ActiveMQ with a database lock on table ACTIVEMQ_LOCK a synchronization monitor (see [http://activemq.apache.orgFeatures/Clustering/ActivePassiveFeatures/Clustering/ActivePassive/Features/Clustering/ActivePassive/jdbc-active-passive.md](http://activemq.apache.orgFeatures/Clustering/ActivePassiveFeatures/Clustering/ActivePassive/Features/Clustering/ActivePassive/jdbc-active-passive)), you have to be careful. If you use only one dataSource, hence only one database, then the lock mechanism shall keep a transaction indefinitely open, and while messages are persisted the transaction log shall grow until you run out of space. It is therefore strongly advised to use a dedicated database for this lock: just define another dataSource targeting a minimal database holding no data (only the ACTIVEMQ_LOCK table) and use it as a lockDataSource in your configuration. Example: diff --git a/src/test.md b/src/test.md index 1765a5eb79..25870fb8eb 100644 --- a/src/test.md +++ b/src/test.md @@ -7,6 +7,8 @@ type: activemq5 [Features](features) > [Persistence](persistence) > [Kaha Persistence](kaha-Features/persistence) > [TEST](Persistence/Kaha Persistence/test) +{% include inclusive-terminology-notice.html %} + [Download](download.md "Download") | [JavaDocs](http://activemq.apache.org/maven/5.7.0/activemq-core/apidocs/) [More...](javadocs.md "JavaDocs") | [Source](source.md "Source") | [Forums](discussion-forums.md "Discussion Forums") | [Support](support.md "Support") TEST BLOG![](https://cwiki.apache.org/confluence/images/icons/emoticons/check.gif) @@ -58,7 +60,7 @@ TEST BLOG![](https://cwiki.apache.org/confluence/images/icons/emoticons/check.gi * [Enterprise Integration Patterns](enterprise-integration-patterns.md "Enterprise Integration Patterns") * [JMX](jmx.md "JMX") * [JMS to JMS Bridge](ConnectivityConnectivity/Connectivity/jms-to-jms-bridge.md "JMS to JMS Bridge") -* [MasterSlave](ClusteringFeatures/Clustering/Features/Clustering/masterslave.md "MasterSlave") +* [ActivePassive](ClusteringFeatures/Clustering/Features/Clustering/activepassive.md "ActivePassive") * [Message Groups](message-groups.md "Message Groups") * [Networks of Brokers](Clustering/networks-of-brokers.md "Networks of Brokers") * [Performance](performance.md "Performance") diff --git a/src/version-5-examples.md b/src/version-5-examples.md index 74f8282686..8c389d6611 100644 --- a/src/version-5-examples.md +++ b/src/version-5-examples.md @@ -41,7 +41,7 @@ activemq:consumer Options ------- -For all options on the commands, run them with `--help` parameter. The up to date, options for [producer](https://github.com/apache/activemq/blob/master/activemq-console/src/main/resources/org/apache/activemq/console/command/producer.txt) and [consumer](https://github.com/apache/activemq/blob/master/activemq-console/src/main/resources/org/apache/activemq/console/command/consumer.txt) can be found in the source. +For all options on the commands, run them with `--help` parameter. The up to date, options for [producer](https://github.com/apache/activemq/blob/main/activemq-console/src/main/resources/org/apache/activemq/console/command/producer.txt) and [consumer](https://github.com/apache/activemq/blob/main/activemq-console/src/main/resources/org/apache/activemq/console/command/consumer.txt) can be found in the source. Examples -------- diff --git a/src/what-open-source-integration-solution-works-best-with-activemq-.md b/src/what-open-source-integration-solution-works-best-with-activemq-.md deleted file mode 100644 index 5d5b21ebf3..0000000000 --- a/src/what-open-source-integration-solution-works-best-with-activemq-.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -layout: default_md -title: What open source integration solution works best with ActiveMQ ? -title-class: page-title-activemq5 -type: activemq5 ---- - - [FAQ](faq) > [General](general) > [What open source integration solution works best with ActiveMQ ?](what-open-source-integration-solution-works-best-with-activemq-) - - -The [Apache Camel](http://camel.apache.org) project has been designed to work easily with ActiveMQ - and comes [embedded](http://activemq.apache.org/camel/how-does-camel-work-with-activemq.html) in both the clients and the broker from ActiveMQ 5.0 onwards. - -[Apache Camel](http://camel.apache.org) supports an extensive range of [integration patterns](http://camel.apache.orgFeatures/enterprise-integration-patterns) to make integration very simple! - -`It also supports a wide range of [transport binding components](http://camel.apache.org/components.html)** - diff --git a/src/xbean-xml-reference-50.md b/src/xbean-xml-reference-50.md index d01d4fd66a..fe0dafdbce 100644 --- a/src/xbean-xml-reference-50.md +++ b/src/xbean-xml-reference-50.md @@ -551,7 +551,7 @@ A Flow provides different dispatch policies within the NMR _\_ -Connects a Slave Broker to a Master when using [Master Slave](masterslave) for High Availability of messages. +Connects a passive Broker to an active broker when using [Active Passive](activepassive) for High Availability of messages. _\_ @@ -2254,7 +2254,7 @@ useDatabaseLock _boolean_ -Sets whether or not an exclusive database lock should be used to enable JDBC Master/Slave. Enabled by default. +Sets whether or not an exclusive database lock should be used to enable JDBC Active/Passive. Enabled by default. useExternalMessageReferences @@ -2568,7 +2568,7 @@ useDatabaseLock _boolean_ -Sets whether or not an exclusive database lock should be used to enable JDBC Master/Slave. Enabled by default. +Sets whether or not an exclusive database lock should be used to enable JDBC Active/Passive. Enabled by default. useJournal @@ -2922,7 +2922,7 @@ _boolean_ ### The _\_ Element -Connects a Slave Broker to a Master when using [Master Slave](masterslave) for High Availability of messages. +Connects a passive Broker to an active broker when using [Active Passive](activepassive) for High Availability of messages. #### Properties @@ -5039,7 +5039,7 @@ A Flow provides different dispatch policies within the NMR _\_ -Connects a Slave Broker to a Master when using [Master Slave](masterslave) for High Availability of messages. +Connects a passive Broker to an active broker when using [Active Passive](activepassive) for High Availability of messages. _\_