You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@activemq.apache.org by jb...@apache.org on 2022/10/18 06:20:16 UTC
[activemq-website] branch main updated: Fix tables in "Classic" docs
This is an automated email from the ASF dual-hosted git repository.
jbonofre pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/activemq-website.git
The following commit(s) were added to refs/heads/main by this push:
new 50b0794ea Fix tables in "Classic" docs
new f33670cd2 Merge pull request #90 from lucastetreault/fix-tables
50b0794ea is described below
commit 50b0794ea65f4e986160d113282512d4f7b7325a
Author: Lucas Tétreault <te...@amazon.com>
AuthorDate: Thu Aug 11 14:13:32 2022 -0700
Fix tables in "Classic" docs
---
src/58-migration-guide.md | 14 +++---
src/static-transport-reference.md | 48 ++++----------------
src/uri-protocols.md | 93 ++++++---------------------------------
3 files changed, 29 insertions(+), 126 deletions(-)
diff --git a/src/58-migration-guide.md b/src/58-migration-guide.md
index 26e485802..163ba4b4c 100644
--- a/src/58-migration-guide.md
+++ b/src/58-migration-guide.md
@@ -15,13 +15,13 @@ There are some changes in 5.8 that may require some code change
All mbeans now share the type=Broker attribute, which gives them containment. In this way, consumers hang off of destinations, which hang off the broker.
The different Mbean types are identified by the presence of specific identifiers in their ObjectNames. The mapping from old to new ObjectName is as follows:
- Type|Old Name|New Name
- ---|---|---
- Broker|Type=Broker|type=Broker
- Destination|Type=Queue\|Topic,Destination=<destination identifier>|type=Broker,destinationType=Queue\|Topic,destinationName=<destination identifier>
- Connector|Type=Connector|type=Broker,connector=clientConnectors
- NetworkConnector|Type=NetworkConnector|type=Broker,connector=networkConnectors
- Connection|Type=Connection|type=Broker,connector=*,connectionViewType=remoteAddress\|clientId
+Type|Old Name|New Name
+---|---|---
+Broker|Type=Broker|type=Broker
+Destination|Type=Queue\|Topic,Destination=<destination identifier>|type=Broker,destinationType=Queue\|Topic,destinationName=<destination identifier>
+Connector|Type=Connector|type=Broker,connector=clientConnectors
+NetworkConnector|Type=NetworkConnector|type=Broker,connector=networkConnectors
+Connection|Type=Connection|type=Broker,connector=*,connectionViewType=remoteAddress\|clientId
3. OSGi integration has changed. The full details are at [OSGi Integration](osgi-integration.html). In summary:
1. There is a single uber OSGI bundle
diff --git a/src/static-transport-reference.md b/src/static-transport-reference.md
index aef945852..b1c06370c 100644
--- a/src/static-transport-reference.md
+++ b/src/static-transport-reference.md
@@ -22,47 +22,15 @@ static:(tcp://localhost:61616,tcp://remotehost:61617?trace=false,vm://localbroke
##### Options
-Option Name
-Default Value
-
-Description
-
-initialReconnectDelay
-
-10
-
-How long to wait before the first reconnect attempt (in ms)
-
-maxReconnectDelay
-
-30000
-
-The maximum amount of time we ever wait between reconnect attempts (in ms)
-
-useExponentialBackOff
-
-true
-
-Should an exponential backoff be used btween reconnect attempts
-
-backOffMultiplier
-
-2
-
-The exponent used in the exponential backoff attempts
-
-maxReconnectAttempts
-
-0
-
-If not 0, then this is the maximum number of reconnect attempts before an error is sent back to the client
-
-minConnectTime
-
-500
-
-If a connaction fails faster than this amount of time then it is considered a connection failure
+Option Name|Default Value|Description
+---|---|---
+initialReconnectDelay|10|How long to wait before the first reconnect attempt (in ms)
+maxReconnectDelay|30000|The maximum amount of time we ever wait between reconnect attempts (in ms)
+useExponentialBackOff|true|Should an exponential backoff be used btween reconnect attempts
+backOffMultiplier|2|The exponent used in the exponential backoff attempts
+maxReconnectAttempts|0|If not 0, then this is the maximum number of reconnect attempts before an error is sent back to the client
+minConnectTime|500|If a connaction fails faster than this amount of time then it is considered a connection failure
##### Notes
diff --git a/src/uri-protocols.md b/src/uri-protocols.md
index f98e78a6c..90d93bb16 100644
--- a/src/uri-protocols.md
+++ b/src/uri-protocols.md
@@ -20,85 +20,20 @@ Connection connection = factory.createConnection();
Protocol Summary
----------------
-Protocol
-
-Example
-
-Description
-
-Server?
-
-VM
-
-vm://host:port
-
-Client connect to each other within the same JVM. This does use an asynchronous channel and a separate worker thread. You can enable sync sending using a query parameter, such as
-
-vm://localhost?async=false
-
-Yes
-
-TCP
-
-tcp://host:port
-
-Client connects to the broker at the given URL
-
-Yes
-
-SSL
-
-ssl://host:port
-
-Client connects to the broker at the given URL
-
-Yes
-
-Failover
-
-failover:(Uri1,Uri2,Uri3,...,UriN)
-
-Provides a list of possible URIs to connect to and one is randomly chosen. If the connection fails then the transport auto-reconnects to a different one
-
-Peer
-
-peer://serviceName
-
-Creates a pure peer to peer network of nodes of a given service name. In peer mode there is no server, nodes just automatically connect and make a peer network. The serviceName allows you to keep networks apart from each other, such as development, testing, UAT and production.
-
-Discovery
-
-discovery://host:port
-
-Uses [Discovery](discovery) to connect to an available broker of the correct channel name. If multiple brokers can be found then one is chosen at random. If the connection fails then another broker is chosen, if available
-
-Zeroconf
-
-zeroconf:_activemq.broker.development.
-
-Uses [Zeroconf](zeroconf) to connect to an available broker of the correct Zeroconf service name. If multiple brokers can be found then one is chosen at random. If the connection fails then another broker is chosen, if available
-
-HTTP
-
-http://host:port
-
-Client connects to the broker using HTTP tunnelling, with XML payloads suitable for going through firewalls
-
-Yes
-
-UDP
-
-udp://host:port
-
-Client connects to the broker at the given URL
-
-multicast
-
-multicast://host:port
-
-No server, though only works for pub/sub. A pure peer based network where all traffic is multicasted around and filtering is performed on the client.
-
-The _Server?_ column above indiciates whether or not a protocol can be used in an ActiveMQ broker transport connector. All of the above protocols can be used in a JMS client to connect to the messaging fabric; only those protocols indicated can be used in a broker-side transport connector.
+Protocol|Example|Description|Server?
+---|---|---|---
+VM|vm://host:port|Client connect to each other within the same JVM. This does use an asynchronous channel and a separate worker thread. You can enable sync sending using a query parameter, such as vm://localhost?async=false|Yes
+TCP|tcp://host:port|Client connects to the broker at the given URL|Yes
+SSL|ssl://host:port|Client connects to the broker at the given URL|Yes
+Failover|failover:(Uri1,Uri2,Uri3,...,UriN)|Provides a list of possible URIs to connect to and one is randomly chosen. If the connection fails then the transport auto-reconnects to a different one
+Peer|peer://serviceName|Creates a pure peer to peer network of nodes of a given service name. In peer mode there is no server, nodes just automatically connect and make a peer network. The serviceName allows you to keep networks apart from each other, such as development, testing, UAT and production.
+Discovery|discovery://host:port|Uses [Discovery](discovery) to connect to an available broker of the correct channel name. If multiple brokers can be found then one is chosen at random. If the connection fails then another broker is chosen, if available
+Zeroconf|zeroconf:_activemq.broker.development.|Uses [Zeroconf](zeroconf) to connect to an available broker of the correct Zeroconf service name. If multiple brokers can be found then one is chosen at random. If the connection fails then another broker is chosen, if available
+HTTP|http://host:port|Client connects to the broker using HTTP tunnelling, with XML payloads suitable for going through firewalls|Yes
+UDP|udp://host:port|Client connects to the broker at the given URL
+multicast|multicast://host:port|No server, though only works for pub/sub. A pure peer based network where all traffic is multicasted around and filtering is performed on the client.
+
+The _Server_ column above indicates whether a protocol can be used in an ActiveMQ broker transport connector. All of the above protocols can be used in a JMS client to connect to the messaging fabric; only those protocols indicated can be used in a broker-side transport connector.
When connecting to an ActiveMQ broker, this could reside locally inside your JVM or be remote on another machine somewhere. If you want to enable the deployment of the ActiveMQ inside your JVM you can enable the useEmbeddedBroker property on the [ActiveMQConnectionFactory](http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html).