activemq-artemis/docs/migration-guide/_connectors.adoc

73 lines
3.3 KiB
Plaintext
Raw Normal View History

ARTEMIS-4383 migrate user docs to AsciiDoc Markdown, which is currently used for user-facing documentation, is good for a lot of things. However, it's not great for the kind of complex documentation we have and our need to produce both multi-page HTML and single-page PDF output via Maven. Markdown lacks features which would make the documentation easier to read, easier to navigate, and just look better overall. The current tool-chain uses honkit and a tool called Calibre. Honkit is written in TypeScript and is installed via NPM. Calibre is a native tool so it must be installed via an OS-specific package manager. All this complexity makes building, releasing, uploading, etc. a pain. AsciiDoc is relatively simple like Markdown, but it has more features for presentation and navigation not to mention Java-based Maven tooling to generate both HTML and PDF. Migrating will improve both the appearance of the documentation as well as the processes to generate and upload it. This commit contains the following changes: - Convert all the Markdown for the User Manual, Migration Guide, and Hacking guide to AsciiDoc via kramdown [1]. - Update the `artemis-website` build to use AsciiDoctor Maven tooling. - Update `RELEASING.md` with simplified instructions. - Update Hacking Guide with simplified instructions. - Use AsciiDoc link syntax in Artemis Maven doc plugin. - Drop EPUB & MOBI docs for User Manual as well as PDF for the Hacking Guide. All docs will be HTML only except for the User Manual which will have PDF. - Move all docs up out of their respective "en" directory. This was a hold-over from when we had docs in different languages. - Migration & Hacking Guides are now single-page HTML since they are relatively short. - Refactor README.md to simplify and remove redundant content. Benefits of the change: - Much simplified tooling. No more NPM packages or native tools. - Auto-generated table of contents for every chapter. - Auto-generated anchor links for every sub-section. - Overall more appealing presentation. - All docs will use the ActiveMQ favicon. - No more manual line-wrapping! AsciiDoc recommends one sentence per line and paragraphs are separated by a blank line. - AsciiDoctor plugins for IDEA are quite good. - Resulting HTML is less than *half* of the previous size. All previous links/bookmarks should continue to work. [1] https://github.com/asciidoctor/kramdown-asciidoc
2023-07-27 23:45:17 -04:00
= Connectors
After broker is started, you'll want to connect your clients to it.
So, let's start with comparing ActiveMQ and Artemis configurations in area of client connectors.
In ActiveMQ terminology, they are called _transport connectors_, and the default configuration looks something like this (in `conf/activemq.xml`).
[,xml]
----
<transportConnectors>
<transportConnector name="openwire" uri="tcp://0.0.0.0:61616?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
<transportConnector name="amqp" uri="amqp://0.0.0.0:5672?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
<transportConnector name="stomp" uri="stomp://0.0.0.0:61613?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
<transportConnector name="mqtt" uri="mqtt://0.0.0.0:1883?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
<transportConnector name="ws" uri="ws://0.0.0.0:61614?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
</transportConnectors>
----
In Artemis, client connectors are called _acceptors_ and they are configured in `etc/broker.xml` like this
[,xml]
----
<acceptors>
<acceptor name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE</acceptor>
<acceptor name="amqp">tcp://0.0.0.0:5672?protocols=AMQP</acceptor>
<acceptor name="stomp">tcp://0.0.0.0:61613?protocols=STOMP</acceptor>
<acceptor name="hornetq">tcp://0.0.0.0:5445?protocols=HORNETQ,STOMP</acceptor>
<acceptor name="mqtt">tcp://0.0.0.0:1883?protocols=MQTT</acceptor>
</acceptors>
----
As you can notice the syntax is very similar, but there are still some differences that we need to understand.
First, as we said earlier, there's no notion of blocking and non-blocking (nio) transport in Artemis, so you should treat everything as non-blocking.
Also, in Artemis the low level transport is distinct from the actual messaging protocol (like AMQP or MQTT) used on top of it.
One acceptor can handle multiple messaging protocols on the same port.
By default, all protocols are accepted on the single port, but you can restrict this using the `protocols=X,Y` uri attribute pattern as shown in the example above.
Besides _tcp_ network protocol, Artemis support _InVm_ and _Web Socket_ transports.
The _InVm_ transport is similar to ActiveMQ's _vm_ transport and is used to connect clients to the embedded broker.
The difference is that you can use any messaging protocol on top of _InVm_ transport in Artemis, while _vm_ transport in ActiveMQ is tied to OpenWire.
One of the advantages of using Netty for IO layer, is that Web Sockets are supported out of the box.
So, there's no need for the separate _ws_ transport like in ActiveMQ, the _tcp_ (Netty) acceptor in Artemis will detect Web Socket clients and handle them accordingly.
To summarize this topic, here's a table that shows you how to migrate your ActiveMQ transport connectors to the Artemis acceptors
|===
| ActiveMQ | Artemis (options in the acceptor URL)
| OpenWire
| protocols=OpenWire (version 10+)
| NIO
| -
| AMQP
| protocols=AMQP
| STOMP
| protocols=STOMP
| VM (OpenWire only)
| InVM (all protocols, peer to tcp)
| HTTP (OpenWire-based)
| -
| MQTT
| protocols=MQTT
| WebSocket (STOMP and MQTT)
| handled by tcp (all protocols)
|===