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 <[email protected]>
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).
