| |
| <!DOCTYPE HTML> |
| <html lang="" > |
| <head> |
| <title>Protocols and Interoperability ยท ActiveMQ Artemis Documentation</title> |
| <meta charset="UTF-8"> |
| <meta http-equiv="X-UA-Compatible" content="IE=edge" /> |
| <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> |
| <meta name="description" content=""> |
| <meta name="generator" content="GitBook 3.1.1"> |
| |
| |
| |
| |
| <link rel="stylesheet" href="gitbook/style.css"> |
| |
| |
| |
| |
| <link rel="stylesheet" href="gitbook/gitbook-plugin-highlight/website.css"> |
| |
| |
| |
| <link rel="stylesheet" href="gitbook/gitbook-plugin-search/search.css"> |
| |
| |
| |
| <link rel="stylesheet" href="gitbook/gitbook-plugin-fontsettings/website.css"> |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| <meta name="HandheldFriendly" content="true"/> |
| <meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no"> |
| <meta name="apple-mobile-web-app-capable" content="yes"> |
| <meta name="apple-mobile-web-app-status-bar-style" content="black"> |
| <link rel="apple-touch-icon-precomposed" sizes="152x152" href="gitbook/images/apple-touch-icon-precomposed-152.png"> |
| <link rel="shortcut icon" href="gitbook/images/favicon.ico" type="image/x-icon"> |
| |
| |
| <link rel="next" href="tools.html" /> |
| |
| |
| <link rel="prev" href="intercepting-operations.html" /> |
| |
| |
| </head> |
| <body> |
| |
| <div class="book"> |
| <div class="book-summary"> |
| |
| |
| <div id="book-search-input" role="search"> |
| <input type="text" placeholder="Type to search" /> |
| </div> |
| |
| |
| <nav role="navigation"> |
| |
| |
| |
| <ul class="summary"> |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| <li class="chapter " data-level="1.1" data-path="./"> |
| |
| <a href="./"> |
| |
| |
| Introduction |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.2" data-path="notice.html"> |
| |
| <a href="notice.html"> |
| |
| |
| Legal Notice |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.3" data-path="preface.html"> |
| |
| <a href="preface.html"> |
| |
| |
| Preface |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.4" data-path="project-info.html"> |
| |
| <a href="project-info.html"> |
| |
| |
| Project Info |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.5" data-path="messaging-concepts.html"> |
| |
| <a href="messaging-concepts.html"> |
| |
| |
| Messaging Concepts |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.6" data-path="architecture.html"> |
| |
| <a href="architecture.html"> |
| |
| |
| Architecture |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.7" data-path="using-server.html"> |
| |
| <a href="using-server.html"> |
| |
| |
| Using the Server |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.8" data-path="using-jms.html"> |
| |
| <a href="using-jms.html"> |
| |
| |
| Using JMS |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.9" data-path="using-core.html"> |
| |
| <a href="using-core.html"> |
| |
| |
| Using Core |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.10" data-path="jms-core-mapping.html"> |
| |
| <a href="jms-core-mapping.html"> |
| |
| |
| Mapping JMS Concepts to the Core API |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.11" data-path="client-classpath.html"> |
| |
| <a href="client-classpath.html"> |
| |
| |
| The Client Classpath |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.12" data-path="examples.html"> |
| |
| <a href="examples.html"> |
| |
| |
| Examples |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.13" data-path="wildcard-routing.html"> |
| |
| <a href="wildcard-routing.html"> |
| |
| |
| Routing Messages With Wild Cards |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.14" data-path="wildcard-syntax.html"> |
| |
| <a href="wildcard-syntax.html"> |
| |
| |
| Understanding the Apache ActiveMQ Artemis Wildcard Syntax |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.15" data-path="filter-expressions.html"> |
| |
| <a href="filter-expressions.html"> |
| |
| |
| Filter Expressions |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.16" data-path="persistence.html"> |
| |
| <a href="persistence.html"> |
| |
| |
| Persistence |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.17" data-path="configuring-transports.html"> |
| |
| <a href="configuring-transports.html"> |
| |
| |
| Configuring Transports |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.18" data-path="config-reload.html"> |
| |
| <a href="config-reload.html"> |
| |
| |
| Configuration Reload |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.19" data-path="connection-ttl.html"> |
| |
| <a href="connection-ttl.html"> |
| |
| |
| Detecting Dead Connections |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.20" data-path="slow-consumers.html"> |
| |
| <a href="slow-consumers.html"> |
| |
| |
| Detecting Slow Consumers |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.21" data-path="network-isolation.html"> |
| |
| <a href="network-isolation.html"> |
| |
| |
| Avoiding Network Isolation |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.22" data-path="transaction-config.html"> |
| |
| <a href="transaction-config.html"> |
| |
| |
| Resource Manager Configuration |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.23" data-path="flow-control.html"> |
| |
| <a href="flow-control.html"> |
| |
| |
| Flow Control |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.24" data-path="send-guarantees.html"> |
| |
| <a href="send-guarantees.html"> |
| |
| |
| Guarantees of sends and commits |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.25" data-path="undelivered-messages.html"> |
| |
| <a href="undelivered-messages.html"> |
| |
| |
| Message Redelivery and Undelivered Messages |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.26" data-path="message-expiry.html"> |
| |
| <a href="message-expiry.html"> |
| |
| |
| Message Expiry |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.27" data-path="large-messages.html"> |
| |
| <a href="large-messages.html"> |
| |
| |
| Large Messages |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.28" data-path="paging.html"> |
| |
| <a href="paging.html"> |
| |
| |
| Paging |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.29" data-path="queue-attributes.html"> |
| |
| <a href="queue-attributes.html"> |
| |
| |
| Queue Attributes |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.30" data-path="scheduled-messages.html"> |
| |
| <a href="scheduled-messages.html"> |
| |
| |
| Scheduled Messages |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.31" data-path="last-value-queues.html"> |
| |
| <a href="last-value-queues.html"> |
| |
| |
| Last-Value Queues |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.32" data-path="message-grouping.html"> |
| |
| <a href="message-grouping.html"> |
| |
| |
| Message Grouping |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.33" data-path="pre-acknowledge.html"> |
| |
| <a href="pre-acknowledge.html"> |
| |
| |
| Extra Acknowledge Modes |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.34" data-path="management.html"> |
| |
| <a href="management.html"> |
| |
| |
| Management |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.35" data-path="security.html"> |
| |
| <a href="security.html"> |
| |
| |
| Security |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.36" data-path="resource-limits.html"> |
| |
| <a href="resource-limits.html"> |
| |
| |
| Resource Limits |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.37" data-path="jms-bridge.html"> |
| |
| <a href="jms-bridge.html"> |
| |
| |
| The JMS Bridge |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.38" data-path="client-reconnection.html"> |
| |
| <a href="client-reconnection.html"> |
| |
| |
| Client Reconnection and Session Reattachment |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.39" data-path="diverts.html"> |
| |
| <a href="diverts.html"> |
| |
| |
| Diverting and Splitting Message Flows |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.40" data-path="core-bridges.html"> |
| |
| <a href="core-bridges.html"> |
| |
| |
| Core Bridges |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.41" data-path="duplicate-detection.html"> |
| |
| <a href="duplicate-detection.html"> |
| |
| |
| Duplicate Message Detection |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.42" data-path="clusters.html"> |
| |
| <a href="clusters.html"> |
| |
| |
| Clusters |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.43" data-path="ha.html"> |
| |
| <a href="ha.html"> |
| |
| |
| High Availability and Failover |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.44" data-path="graceful-shutdown.html"> |
| |
| <a href="graceful-shutdown.html"> |
| |
| |
| Graceful Server Shutdown |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.45" data-path="libaio.html"> |
| |
| <a href="libaio.html"> |
| |
| |
| Libaio Native Libraries |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.46" data-path="thread-pooling.html"> |
| |
| <a href="thread-pooling.html"> |
| |
| |
| Thread management |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.47" data-path="logging.html"> |
| |
| <a href="logging.html"> |
| |
| |
| Logging |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.48" data-path="rest.html"> |
| |
| <a href="rest.html"> |
| |
| |
| REST Interface |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.49" data-path="embedding-activemq.html"> |
| |
| <a href="embedding-activemq.html"> |
| |
| |
| Embedding Apache ActiveMQ Artemis |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.50" data-path="karaf.html"> |
| |
| <a href="karaf.html"> |
| |
| |
| Apache Karaf |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.51" data-path="spring-integration.html"> |
| |
| <a href="spring-integration.html"> |
| |
| |
| Spring Integration |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.52" data-path="aerogear-integration.html"> |
| |
| <a href="aerogear-integration.html"> |
| |
| |
| AeroGear Integration |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.53" data-path="vertx-integration.html"> |
| |
| <a href="vertx-integration.html"> |
| |
| |
| VertX Integration |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.54" data-path="cdi-integration.html"> |
| |
| <a href="cdi-integration.html"> |
| |
| |
| CDI Integration |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.55" data-path="intercepting-operations.html"> |
| |
| <a href="intercepting-operations.html"> |
| |
| |
| Intercepting Operations |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter active" data-level="1.56" data-path="protocols-interoperability.html"> |
| |
| <a href="protocols-interoperability.html"> |
| |
| |
| Protocols and Interoperability |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.57" data-path="tools.html"> |
| |
| <a href="tools.html"> |
| |
| |
| Tools |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.58" data-path="maven-plugin.html"> |
| |
| <a href="maven-plugin.html"> |
| |
| |
| Maven Plugin |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.59" data-path="unit-testing.html"> |
| |
| <a href="unit-testing.html"> |
| |
| |
| Unit Testing |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.60" data-path="perf-tuning.html"> |
| |
| <a href="perf-tuning.html"> |
| |
| |
| Troubleshooting and Performance Tuning |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.61" data-path="configuration-index.html"> |
| |
| <a href="configuration-index.html"> |
| |
| |
| Configuration Reference |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| |
| |
| |
| <li class="divider"></li> |
| |
| <li> |
| <a href="https://www.gitbook.com" target="blank" class="gitbook-link"> |
| Published with GitBook |
| </a> |
| </li> |
| </ul> |
| |
| |
| </nav> |
| |
| |
| </div> |
| |
| <div class="book-body"> |
| |
| <div class="body-inner"> |
| |
| |
| |
| <div class="book-header" role="navigation"> |
| |
| |
| <!-- Title --> |
| <h1> |
| <i class="fa fa-circle-o-notch fa-spin"></i> |
| <a href="." >Protocols and Interoperability</a> |
| </h1> |
| </div> |
| |
| |
| |
| |
| <div class="page-wrapper" tabindex="-1" role="main"> |
| <div class="page-inner"> |
| |
| <div id="book-search-results"> |
| <div class="search-noresults"> |
| |
| <section class="normal markdown-section"> |
| |
| <h1 id="protocols-and-interoperability">Protocols and Interoperability</h1> |
| <h2 id="protocols">Protocols</h2> |
| <p>ActiveMQ Artemis has a plugable protocol architecture. Protocol plugins come in the form of ActiveMQ Artemis protocol |
| modules. Each protocol module should be added to the brokers class path and are loaded by the broker at boot time. |
| ActiveMQ Artemis ships with 5 protocol modules out of the box. The 5 modules offer support for the following protocols:</p> |
| <ul> |
| <li>AMQP</li> |
| <li>OpenWire</li> |
| <li>MQTT</li> |
| <li>STOMP</li> |
| <li>HornetQ</li> |
| </ul> |
| <p>In addition to the protocols above ActiveMQ Artemis also offers support for it's own highly performant native protocol |
| "Core".</p> |
| <h2 id="configuring-protocols">Configuring protocols</h2> |
| <p>In order to make use of a particular protocol, a transport must be configured with the desired protocol enabled. There |
| is a whole section on configuring transports that can be found <a href="configuring-transports.html">here</a>.</p> |
| <p>The default configuration shipped with the ActiveMQ Artemis distribution comes with a number of acceptors already |
| defined, one for each of the above protocols plus a generic acceptor that supports all protocols. To enable a |
| protocol on a particular acceptor simply add a url parameter "protocol=AMQP,STOMP" to the acceptor url. Where the value |
| of the parameter is a comma separated list of protocol names. If the protocol parameter is omitted from the url all |
| protocols are enabled.</p> |
| <pre><code><!-- The following example enables only MQTT on port 1883 --> |
| <acceptors> |
| <acceptor>tcp://localhost:1883?protocols=MQTT</acceptor> |
| </acceptors> |
| |
| <!-- The following example enables MQTT and AMQP on port 61617 --> |
| <acceptors> |
| <acceptor>tcp://localhost:1883?protocols=MQTT,AMQP</acceptor> |
| </acceptors> |
| |
| <!-- The following example enables all protocols on 61616 --> |
| <acceptors> |
| <acceptor>tcp://localhost:61616</acceptor> |
| </acceptors> |
| </code></pre><h2 id="amqp">AMQP</h2> |
| <p>Apache ActiveMQ Artemis supports the <a href="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=amqp" target="_blank">AMQP |
| 1.0</a> |
| specification. To enable AMQP you must configure a Netty Acceptor to |
| receive AMQP clients, like so:</p> |
| <pre><code><acceptor name="amqp-acceptor">tcp://localhost:5672?protocols=AMQP</acceptor> |
| </code></pre><p>Apache ActiveMQ Artemis will then accept AMQP 1.0 clients on port 5672 which is the |
| default AMQP port.</p> |
| <p>There are 2 AMQP examples available see proton-j and proton-ruby which |
| use the qpid Java and Ruby clients respectively.</p> |
| <h3 id="amqp-and-security">AMQP and security</h3> |
| <p>The Apache ActiveMQ Artemis Server accepts AMQP SASL Authentication and will use this |
| to map onto the underlying session created for the connection so you can |
| use the normal Apache ActiveMQ Artemis security configuration.</p> |
| <h3 id="amqp-links">AMQP Links</h3> |
| <p>An AMQP Link is a uni directional transport for messages between a |
| source and a target, i.e. a client and the Apache ActiveMQ Artemis Broker. A link will |
| have an endpoint of which there are 2 kinds, a Sender and A Receiver. At |
| the Broker a Sender will have its messages converted into an Apache ActiveMQ Artemis |
| Message and forwarded to its destination or target. A Receiver will map |
| onto an Apache ActiveMQ Artemis Server Consumer and convert Apache ActiveMQ Artemis messages back into |
| AMQP messages before being delivered.</p> |
| <h3 id="amqp-and-destinations">AMQP and destinations</h3> |
| <p>If an AMQP Link is dynamic then a temporary queue will be created and |
| either the remote source or remote target address will be set to the |
| name of the temporary queue. If the Link is not dynamic then the the |
| address of the remote target or source will used for the queue. If this |
| does not exist then an exception will be sent</p> |
| <blockquote> |
| <p><strong>Note</strong></p> |
| <p>For the next version we will add a flag to aut create durable queue |
| but for now you will have to add them via the configuration</p> |
| </blockquote> |
| <h3 id="amqp-and-topics">AMQP and Topics</h3> |
| <p>Although amqp has no notion of topics it is still possible to treat amqp consumers or receivers as subscriptions rather |
| than just consumers on a queue. By default any receiving link that attaches to an address with the prefix <code>jms.topic.</code> |
| will be treated as a subscription and a subscription queue will be created. If the Terminus Durability is either UNSETTLED_STATE |
| or CONFIGURATION then the queue will be made durable, similar to a JMS durable subscription and given a name made up from |
| the container id and the link name, something like <code>my-container-id:my-link-name</code>. if the Terminus Durability is configured |
| as NONE then a volatile queue will be created.</p> |
| <p>The prefix can be changed by configuring the Acceptor and setting the <code>pubSubPrefix</code> like so</p> |
| <blockquote> |
| <acceptor name="amqp">tcp://0.0.0.0:5672?protocols=AMQP;pubSubPrefix=foo.bar.</acceptor> |
| |
| </blockquote> |
| <p>Artemis also supports the qpid-jms client and will respect its use of topics regardless of the prefix used for the address. </p> |
| <h3 id="amqp-and-coordinations---handling-transactions">AMQP and Coordinations - Handling Transactions</h3> |
| <p>An AMQP links target can also be a Coordinator, the Coordinator is used |
| to handle transactions. If a coordinator is used the the underlying |
| HormetQ Server session will be transacted and will be either rolled back |
| or committed via the coordinator.</p> |
| <blockquote> |
| <p><strong>Note</strong></p> |
| <p>AMQP allows the use of multiple transactions per session, |
| <code>amqp:multi-txns-per-ssn</code>, however in this version Apache ActiveMQ Artemis will only |
| support single transactions per session</p> |
| </blockquote> |
| <h2 id="openwire">OpenWire</h2> |
| <p>Apache ActiveMQ Artemis now supports the |
| <a href="http://activemq.apache.org/openwire.html" target="_blank">OpenWire</a> protocol so that an |
| Apache ActiveMQ Artemis JMS client can talk directly to an Apache ActiveMQ Artemis server. To enable |
| OpenWire support you must configure a Netty Acceptor, like so:</p> |
| <pre><code><acceptor name="openwire-acceptor">tcp://localhost:61616?protocols=OPENWIRE</acceptor> |
| </code></pre><p>The Apache ActiveMQ Artemis server will then listens on port 61616 for incoming |
| openwire commands. Please note the "protocols" is not mandatory here. |
| The openwire configuration conforms to Apache ActiveMQ Artemis's "Single Port" feature. |
| Please refer to <a href="#configuring-transports.single-port">Configuring Single |
| Port</a> for details.</p> |
| <p>Please refer to the openwire example for more coding details.</p> |
| <p>Currently we support Apache ActiveMQ Artemis clients that using standard JMS APIs. In |
| the future we will get more supports for some advanced, Apache ActiveMQ Artemis |
| specific features into Apache ActiveMQ Artemis.</p> |
| <h3 id="connection-monitoring">Connection Monitoring</h3> |
| <p>OpenWire has a few parameters to control how each connection is monitored, they are:</p> |
| <ul> |
| <li><p>maxInactivityDuration: |
| It specifies the time (milliseconds) after which the connection is closed by the broker if no data was received. |
| Default value is 30000.</p> |
| </li> |
| <li><p>maxInactivityDurationInitalDelay: |
| It specifies the maximum delay (milliseconds) before inactivity monitoring is started on the connection. |
| It can be useful if a broker is under load with many connections being created concurrently. |
| Default value is 10000.</p> |
| </li> |
| <li><p>useInactivityMonitor: |
| A value of false disables the InactivityMonitor completely and connections will never time out. |
| By default it is enabled. On broker side you don't neet set this. Instead you can set the |
| connection-ttl to -1.</p> |
| </li> |
| <li><p>useKeepAlive: |
| Whether or not to send a KeepAliveInfo on an idle connection to prevent it from timing out. |
| Enabled by default. Disabling the keep alive will still make connections time out if no data |
| was received on the connection for the specified amount of time.</p> |
| </li> |
| </ul> |
| <p>Note at the beginning the InactivityMonitor negotiates the appropriate maxInactivityDuration and |
| maxInactivityDurationInitalDelay. The shortest duration is taken for the connection.</p> |
| <p>More details please see <a href="http://activemq.apache.org/activemq-inactivitymonitor.html" target="_blank">ActiveMQ InactivityMonitor</a>.</p> |
| <h2 id="mqtt">MQTT</h2> |
| <p>MQTT is a light weight, client to server, publish / subscribe messaging protocol. MQTT has been specifically |
| designed to reduce transport overhead (and thus network traffic) and code footprint on client devices. |
| For this reason MQTT is ideally suited to constrained devices such as sensors and actuators and is quickly |
| becoming the defacto standard communication protocol for IoT.</p> |
| <p>Apache ActiveMQ Artemis supports MQTT v3.1.1 (and also the older v3.1 code message format). To enable MQTT, |
| simply add an appropriate acceptor with the MQTT protocol enabled. For example:</p> |
| <pre><code><acceptor name="mqtt">tcp://localhost:1883?protocols=MQTT</acceptor> |
| </code></pre><p>By default the configuration shipped with Apache ActiveMQ Artemis has the above acceptor already defined, MQTT is |
| also active by default on the generic acceptor defined on port 61616 (where all protocols are enabled), in the out |
| of the box configuration.</p> |
| <p>The best source of information on the MQTT protocol is in the specification. The MQTT v3.1.1 specification can |
| be downloaded from the OASIS website here: <a href="http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html" target="_blank">http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html</a></p> |
| <p>Some note worthy features of MQTT are explained below:</p> |
| <h3 id="mqtt-quality-of-service">MQTT Quality of Service</h3> |
| <p>MQTT offers 3 quality of service levels.</p> |
| <p>Each message (or topic subscription) can define a quality of service that is associated with it. The quality of service |
| level defined on a topic is the maximum level a client is willing to accept. The quality of service level on a |
| message is the desired quality of service level for this message. The broker will attempt to deliver messages to |
| subscribers at the highest quality of service level based on what is defined on the message and topic subscription.</p> |
| <p>Each quality of service level offers a level of guarantee by which a message is sent or received:</p> |
| <ul> |
| <li><p>QoS 0: AT MOST ONCE: Guarantees that a particular message is only ever received by the subscriber a maximum of one time. |
| This does mean that the message may never arrive. The sender and the receiver will attempt to deliver the message, |
| but if something fails and the message does not reach it's destination (say due to a network connection) the message |
| may be lost. This QoS has the least network traffic overhead and the least burden on the client and the broker and is often |
| useful for telemetry data where it doesn't matter if some of the data is lost.</p> |
| </li> |
| <li><p>QoS 1: AT LEAST ONCE: Guarantees that a message will reach it's intended recipient one or more times. The sender will |
| continue to send the message until it receives an acknowledgment from the recipient, confirming it has received the message. |
| The result of this QoS is that the recipient may receive the message multiple times, and also increases the network |
| overhead than QoS 0, (due to acks). In addition more burden is placed on the sender as it needs to store the message |
| and retry should it fail to receive an ack in a reasonable time.</p> |
| </li> |
| <li><p>QoS 2: EXACTLY ONCE: The most costly of the QoS (in terms of network traffic and burden on sender and receiver) this |
| QoS will ensure that the message is received by a recipient exactly one time. This ensures that the receiver never gets |
| any duplicate copies of the message and will eventually get it, but at the extra cost of network overhead and complexity |
| required on the sender and receiver.</p> |
| </li> |
| </ul> |
| <h3 id="mqtt-retain-messages">MQTT Retain Messages</h3> |
| <p>MQTT has an interesting feature in which messages can be "retained" for a particular address. This means that once a |
| retain message has been sent to an address, any new subscribers to that address will receive the last sent retain |
| message before any others messages, this happens even if the retained message was sent before a client has connected |
| or subscribed. An example of where this feature might be useful is in environments such as IoT where devices need to |
| quickly get the current state of a system when they are on boarded into a system.</p> |
| <h3 id="will-messages">Will Messages</h3> |
| <p>A will message can be sent when a client initially connects to a broker. Clients are able to set a "will |
| message" as part of the connect packet. If the client abnormally disconnects, say due to a device or network failure |
| the broker will proceed to publish the will message to the specified address (as defined also in the connect packet). |
| Other subscribers to the will topic will receive the will message and can react accordingly. This feature can be useful |
| in an IoT style scenario to detect errors across a potentially large scale deployment of devices.</p> |
| <h3 id="wild-card-subscriptions">Wild card subscriptions</h3> |
| <p>MQTT addresses are hierarchical much like a file system, and use "/" character to separate hierarchical levels. |
| Subscribers are able to subscribe to specific topics or to whole branches of a hierarchy.</p> |
| <p>To subscribe to branches of an address hierarchy a subscriber can use wild cards.</p> |
| <p>There are 2 types of wild card in MQTT:</p> |
| <ul> |
| <li><p>"#" Multi level wild card. Adding this wild card to an address would match all branches of the address hierarchy |
| under a specified node. For example: /uk/# Would match /uk/cities, /uk/cities/newcastle and also /uk/rivers/tyne. |
| Subscribing to an address "#" would result in subscribing to all topics in the broker. This can be useful, but should |
| be done so with care since it has significant performance implications.</p> |
| </li> |
| <li><p>"+" Single level wild card. Matches a single level in the address hierarchy. For example /uk/+/stores would |
| match /uk/newcastle/stores but not /uk/cities/newcastle/stores.</p> |
| </li> |
| </ul> |
| <h2 id="stomp">Stomp</h2> |
| <p><a href="http://stomp.github.com/" target="_blank">Stomp</a> is a text-orientated wire protocol |
| that allows Stomp clients to communicate with Stomp Brokers. Apache ActiveMQ Artemis |
| now supports Stomp 1.0, 1.1 and 1.2.</p> |
| <p>Stomp clients are available for several languages and platforms making |
| it a good choice for interoperability.</p> |
| <h2 id="native-stomp-support">Native Stomp support</h2> |
| <p>Apache ActiveMQ Artemis provides native support for Stomp. To be able to send and |
| receive Stomp messages, you must configure a <code>NettyAcceptor</code> with a |
| <code>protocols</code> parameter set to have <code>stomp</code>:</p> |
| <pre><code><acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP</acceptor> |
| </code></pre><p>With this configuration, Apache ActiveMQ Artemis will accept Stomp connections on the |
| port <code>61613</code> (which is the default port of the Stomp brokers).</p> |
| <p>See the <code>stomp</code> example which shows how to configure an Apache ActiveMQ Artemis server |
| with Stomp.</p> |
| <h3 id="limitations">Limitations</h3> |
| <p>Message acknowledgements are not transactional. The ACK frame can not be |
| part of a transaction (it will be ignored if its <code>transaction</code> header is |
| set).</p> |
| <h3 id="stomp-1112-notes">Stomp 1.1/1.2 Notes</h3> |
| <h4 id="virtual-hosting">Virtual Hosting</h4> |
| <p>Apache ActiveMQ Artemis currently doesn't support virtual hosting, which means the |
| 'host' header in CONNECT fram will be ignored.</p> |
| <h3 id="mapping-stomp-destinations-to-apache-activemq-artemis-addresses-and-queues">Mapping Stomp destinations to Apache ActiveMQ Artemis addresses and queues</h3> |
| <p>Stomp clients deals with <em>destinations</em> when sending messages and |
| subscribing. Destination names are simply strings which are mapped to |
| some form of destination on the server - how the server translates these |
| is left to the server implementation.</p> |
| <p>In Apache ActiveMQ Artemis, these destinations are mapped to <em>addresses</em> and <em>queues</em>. |
| When a Stomp client sends a message (using a <code>SEND</code> frame), the |
| specified destination is mapped to an address. When a Stomp client |
| subscribes (or unsubscribes) for a destination (using a <code>SUBSCRIBE</code> or |
| <code>UNSUBSCRIBE</code> frame), the destination is mapped to an Apache ActiveMQ Artemis queue.</p> |
| <h3 id="stomp-heart-beating-and-connection-ttl">STOMP heart-beating and connection-ttl</h3> |
| <p>Well behaved STOMP clients will always send a DISCONNECT frame before |
| closing their connections. In this case the server will clear up any |
| server side resources such as sessions and consumers synchronously. |
| However if STOMP clients exit without sending a DISCONNECT frame or if |
| they crash the server will have no way of knowing immediately whether |
| the client is still alive or not. STOMP connections therefore default to |
| a connection-ttl value of 1 minute (see chapter on |
| <a href="#connection-ttl">connection-ttl</a> for more information. This value can |
| be overridden using the <code>connection-ttl-override</code> property or if you |
| need a specific connectionTtl for your stomp connections without |
| affecting the broker-wide <code>connection-ttl-override</code> setting, you can |
| configure your stomp acceptor with the "connectionTtl" property, which |
| is used to set the ttl for connections that are created from that acceptor. |
| For example:</p> |
| <pre><code><acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP;connectionTtl=20000</acceptor> |
| </code></pre><p>The above configuration will make sure that any Stomp connection that is |
| created from that acceptor and does not include a <code>heart-beat</code> header |
| or disables client-to-server heart-beats by specifying a <code>0</code> value will |
| have its connection-ttl set to 20 seconds. The <code>connectionTtl</code> set on an |
| acceptor will take precedence over <code>connection-ttl-override</code>. The default |
| <code>connectionTtl</code> is 60,000 milliseconds.</p> |
| <p>Since Stomp 1.0 does not support heart-beating then all connections from |
| Stomp 1.0 clients will have a connection TTL imposed upon them by the broker |
| based on the aforementioned configuration options. Likewise, any Stomp 1.1 |
| or 1.2 clients that don't specify a <code>heart-beat</code> header or disable client-to-server |
| heart-beating (e.g. by sending <code>0,X</code> in the <code>heart-beat</code> header) will have |
| a connection TTL imposed upon them by the broker.</p> |
| <p>For Stomp 1.1 and 1.2 clients which send a non-zero client-to-server <code>heart-beat</code> |
| header value then their connection TTL will be set accordingly. However, the broker |
| will not strictly set the connection TTL to the same value as the specified in the |
| <code>heart-beat</code> since even small network delays could then cause spurious disconnects. |
| Instead, the client-to-server value in the <code>heart-beat</code> will be multiplied by the |
| <code>heartBeatConnectionTtlModifer</code> specified on the acceptor. The |
| <code>heartBeatConnectionTtlModifer</code> is a decimal value that defaults to <code>2.0</code> so for |
| example, if a client sends a <code>heart-beat</code> header of <code>1000,0</code> the the connection TTL |
| will be set to <code>2000</code> so that the data or ping frames sent every 1000 milliseconds will |
| have a sufficient cushion so as not to be considered late and trigger a disconnect. |
| This is also in accordance with the Stomp 1.1 and 1.2 specifications which both state, |
| "because of timing inaccuracies, the receiver SHOULD be tolerant and take into account |
| an error margin."</p> |
| <p>The minimum and maximum connection TTL allowed can also be specified on the |
| acceptor via the <code>connectionTtlMin</code> and <code>connectionTtlMax</code> properties respectively. |
| The default <code>connectionTtlMin</code> is 1000 and the default <code>connectionTtlMax</code> is Java's |
| <code>Long.MAX_VALUE</code> meaning there essentially is no max connection TTL by default. |
| Keep in mind that the <code>heartBeatConnectionTtlModifer</code> is relevant here. For |
| example, if a client sends a <code>heart-beat</code> header of <code>20000,0</code> and the acceptor |
| is using a <code>connectionTtlMax</code> of <code>30000</code> and a default <code>heartBeatConnectionTtlModifer</code> |
| of <code>2.0</code> then the connection TTL would be <code>40000</code> (i.e. <code>20000</code> * <code>2.0</code>) which would |
| exceed the <code>connectionTtlMax</code>. In this case the server would respond to the client |
| with a <code>heart-beat</code> header of <code>0,15000</code> (i.e. <code>30000</code> / <code>2.0</code>). As described |
| previously, this is to make sure there is a sufficient cushion for the client |
| heart-beats in accordance with the Stomp 1.1 and 1.2 specifications. The same kind |
| of calculation is done for <code>connectionTtlMin</code>.</p> |
| <p>The minimum server-to-client heart-beat value is 500ms.</p> |
| <blockquote> |
| <p><strong>Note</strong></p> |
| <p>Please note that the STOMP protocol version 1.0 does not contain any |
| heart-beat frame. It is therefore the user's responsibility to make |
| sure data is sent within connection-ttl or the server will assume the |
| client is dead and clean up server side resources. With <code>Stomp 1.1</code> |
| users can use heart-beats to maintain the life cycle of stomp |
| connections.</p> |
| </blockquote> |
| <h3 id="selectorfilter-expressions">Selector/Filter expressions</h3> |
| <p>Stomp subscribers can specify an expression used to select or filter |
| what the subscriber receives using the <code>selector</code> header. The filter |
| expression syntax follows the <em>core filter syntax</em> described in the |
| <a href="filter-expressions.html">Filter Expressions</a> documentation.</p> |
| <h3 id="stomp-and-jms-interoperability">Stomp and JMS interoperability</h3> |
| <h4 id="using-jms-destinations">Using JMS destinations</h4> |
| <p>As explained in <a href="jms-core-mapping.html">Mapping JMS Concepts to the Core API</a>, |
| JMS destinations are also mapped to Apache ActiveMQ Artemis |
| addresses and queues. If you want to use Stomp to send messages to JMS |
| destinations, the Stomp destinations must follow the same convention:</p> |
| <ul> |
| <li><p>send or subscribe to a JMS <em>Queue</em> by prepending the queue name by |
| <code>jms.queue.</code>.</p> |
| <p>For example, to send a message to the <code>orders</code> JMS Queue, the Stomp |
| client must send the frame:</p> |
| <pre><code>SEND |
| destination:jms.queue.orders |
| |
| hello queue orders |
| ^@ |
| </code></pre></li> |
| <li><p>send or subscribe to a JMS <em>Topic</em> by prepending the topic name by |
| <code>jms.topic.</code>.</p> |
| <p>For example to subscribe to the <code>stocks</code> JMS Topic, the Stomp client |
| must send the frame:</p> |
| <pre><code>SUBSCRIBE |
| destination:jms.topic.stocks |
| |
| ^@ |
| </code></pre></li> |
| </ul> |
| <h4 id="sending-and-consuming-stomp-message-from-jms-or-apache-activemq-artemis-core-api">Sending and consuming Stomp message from JMS or Apache ActiveMQ Artemis Core API</h4> |
| <p>Stomp is mainly a text-orientated protocol. To make it simpler to |
| interoperate with JMS and Apache ActiveMQ Artemis Core API, our Stomp implementation |
| checks for presence of the <code>content-length</code> header to decide how to map |
| a Stomp 1.0 message to a JMS Message or a Core message.</p> |
| <p>If the Stomp 1.0 message does <em>not</em> have a <code>content-length</code> header, it will |
| be mapped to a JMS <em>TextMessage</em> or a Core message with a <em>single |
| nullable SimpleString in the body buffer</em>.</p> |
| <p>Alternatively, if the Stomp 1.0 message <em>has</em> a <code>content-length</code> header, it |
| will be mapped to a JMS <em>BytesMessage</em> or a Core message with a <em>byte[] |
| in the body buffer</em>.</p> |
| <p>The same logic applies when mapping a JMS message or a Core message to |
| Stomp. A Stomp 1.0 client can check the presence of the <code>content-length</code> |
| header to determine the type of the message body (String or bytes).</p> |
| <h4 id="durable-subscriptions">Durable Subscriptions</h4> |
| <p>The <code>SUBSCRIBE</code> and <code>UNSUBSCRIBE</code> frames can be augmented with special headers to create |
| and destroy durable subscriptions respectively.</p> |
| <p>To create a durable subscription the <code>client-id</code> header must be set on the <code>CONNECT</code> frame |
| and the <code>durable-subscription-name</code> must be set on the <code>SUBSCRIBE</code> frame. The combination |
| of these two headers will form the identity of the durable subscription.</p> |
| <p>To delete a durable subscription the <code>client-id</code> header must be set on the <code>CONNECT</code> frame |
| and the <code>durable-subscription-name</code> must be set on the <code>UNSUBSCRIBE</code> frame. The values for |
| these headers should match what was set on the <code>SUBSCRIBE</code> frame to delete the corresponding |
| durable subscription.</p> |
| <p>It is possible to pre-configure durable subscriptions since the Stomp implementation creates |
| the queue used for the durable subscription in a deterministic way (i.e. using the format of |
| <code>client-id</code>.<code>subscription-name</code>). For example, if you wanted to configure a durable |
| subscription on the JMS topic <code>myTopic</code> with a client-id of <code>myclientid</code> and a subscription |
| name of <code>mysubscriptionname</code> then first you'd configure the topic:</p> |
| <pre><code> <jms xmlns="urn:activemq:jms"> |
| ... |
| <topic name="myTopic"/> |
| ... |
| </jms> |
| </code></pre><p>Then configure the durable subscription:</p> |
| <pre><code> <core xmlns="urn:activemq:core"> |
| ... |
| <queues> |
| <queue name="myclientid.mysubscription"> |
| <address>jms.topic.myTopic</address> |
| </queue> |
| </queues> |
| ... |
| </core> |
| </code></pre><h4 id="message-ids-for-stomp-messages">Message IDs for Stomp messages</h4> |
| <p>When receiving Stomp messages via a JMS consumer or a QueueBrowser, the |
| messages have no properties like JMSMessageID by default. However this |
| may bring some inconvenience to clients who wants an ID for their |
| purpose. Apache ActiveMQ Artemis Stomp provides a parameter to enable message ID on |
| each incoming Stomp message. If you want each Stomp message to have a |
| unique ID, just set the <code>stompEnableMessageId</code> to true. For example:</p> |
| <pre><code><acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP;stompEnableMessageId=true</acceptor> |
| </code></pre><p>When the server starts with the above setting, each stomp message sent |
| through this acceptor will have an extra property added. The property |
| key is <code>amq-message-id</code> and the value is a String representation of a |
| long type internal message id prefixed with "<code>STOMP</code>", like:</p> |
| <pre><code>amq-message-id : STOMP12345 |
| </code></pre><p>If <code>stomp-enable-message-id</code> is not specified in the configuration, |
| default is <code>false</code>.</p> |
| <h4 id="handling-of-large-messages-with-stomp">Handling of Large Messages with Stomp</h4> |
| <p>Stomp clients may send very large bodys of frames which can exceed the |
| size of Apache ActiveMQ Artemis server's internal buffer, causing unexpected errors. To |
| prevent this situation from happening, Apache ActiveMQ Artemis provides a stomp |
| configuration attribute <code>stompMinLargeMessageSize</code>. This attribute |
| can be configured inside a stomp acceptor, as a parameter. For example:</p> |
| <pre><code> <acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP;stompMinLargeMessageSize=10240</acceptor> |
| </code></pre><p>The type of this attribute is integer. When this attributed is |
| configured, Apache ActiveMQ Artemis server will check the size of the body of each |
| Stomp frame arrived from connections established with this acceptor. If |
| the size of the body is equal or greater than the value of |
| <code>stompMinLargeMessageSize</code>, the message will be persisted as a large |
| message. When a large message is delievered to a stomp consumer, the |
| HorentQ server will automatically handle the conversion from a large |
| message to a normal message, before sending it to the client.</p> |
| <p>If a large message is compressed, the server will uncompressed it before |
| sending it to stomp clients. The default value of |
| <code>stompMinLargeMessageSize</code> is the same as the default value of |
| <a href="#large-messages.core.config">min-large-message-size</a>.</p> |
| <h3 id="stomp-over-web-sockets">Stomp Over Web Sockets</h3> |
| <p>Apache ActiveMQ Artemis also support Stomp over <a href="http://dev.w3.org/html5/websockets/" target="_blank">Web |
| Sockets</a>. Modern web browser which |
| support Web Sockets can send and receive Stomp messages from Apache ActiveMQ Artemis.</p> |
| <p>Stomp over Web Sockets is supported via the normal Stomp acceptor:</p> |
| <pre><code><acceptor name="stomp-ws-acceptor">tcp://localhost:61614?protocols=STOMP</acceptor> |
| </code></pre><p>With this configuration, Apache ActiveMQ Artemis will accept Stomp connections over Web |
| Sockets on the port <code>61614</code>. Web browser can |
| then connect to <code>ws://<server>:61614</code> using a Web Socket to send |
| and receive Stomp messages.</p> |
| <p>A companion JavaScript library to ease client-side development is |
| available from <a href="http://github.com/jmesnil/stomp-websocket" target="_blank">GitHub</a> |
| (please see its <a href="http://jmesnil.net/stomp-websocket/doc/" target="_blank">documentation</a> |
| for a complete description).</p> |
| <p>The <code>stomp-websockets</code> example shows how to configure Apache ActiveMQ Artemis server to |
| have web browsers and Java applications exchanges messages on a JMS |
| topic.</p> |
| <h2 id="rest">REST</h2> |
| <p>Please see <a href="rest.html">Rest Interface</a></p> |
| |
| |
| </section> |
| |
| </div> |
| <div class="search-results"> |
| <div class="has-results"> |
| |
| <h1 class="search-results-title"><span class='search-results-count'></span> results matching "<span class='search-query'></span>"</h1> |
| <ul class="search-results-list"></ul> |
| |
| </div> |
| <div class="no-results"> |
| |
| <h1 class="search-results-title">No results matching "<span class='search-query'></span>"</h1> |
| |
| </div> |
| </div> |
| </div> |
| |
| </div> |
| </div> |
| |
| </div> |
| |
| |
| |
| <a href="intercepting-operations.html" class="navigation navigation-prev " aria-label="Previous page: Intercepting Operations"> |
| <i class="fa fa-angle-left"></i> |
| </a> |
| |
| |
| <a href="tools.html" class="navigation navigation-next " aria-label="Next page: Tools"> |
| <i class="fa fa-angle-right"></i> |
| </a> |
| |
| |
| |
| </div> |
| |
| <script> |
| var gitbook = gitbook || []; |
| gitbook.push(function() { |
| gitbook.page.hasChanged({"page":{"title":"Protocols and Interoperability","level":"1.56","depth":1,"next":{"title":"Tools","level":"1.57","depth":1,"path":"tools.md","ref":"tools.md","articles":[]},"previous":{"title":"Intercepting Operations","level":"1.55","depth":1,"path":"intercepting-operations.md","ref":"intercepting-operations.md","articles":[]},"dir":"ltr"},"config":{"plugins":[],"styles":{"website":"styles/website.css","pdf":"styles/pdf.css","epub":"styles/epub.css","mobi":"styles/mobi.css","ebook":"styles/ebook.css","print":"styles/print.css"},"pluginsConfig":{"highlight":{},"search":{},"lunr":{"maxIndexSize":1000000},"sharing":{"facebook":true,"twitter":true,"google":false,"weibo":false,"instapaper":false,"vk":false,"all":["facebook","google","twitter","weibo","instapaper"]},"fontsettings":{"theme":"white","family":"sans","size":2},"theme-default":{"styles":{"website":"styles/website.css","pdf":"styles/pdf.css","epub":"styles/epub.css","mobi":"styles/mobi.css","ebook":"styles/ebook.css","print":"styles/print.css"},"showLevel":false}},"github":"apache/activemq-artemis","theme":"default","githubHost":"https://github.com/","pdf":{"pageNumbers":true,"fontSize":12,"fontFamily":"Arial","paperSize":"a4","chapterMark":"pagebreak","pageBreaksBefore":"/","margin":{"right":62,"left":62,"top":56,"bottom":56}},"structure":{"langs":"LANGS.md","readme":"README.md","glossary":"GLOSSARY.md","summary":"SUMMARY.md"},"variables":{},"title":"ActiveMQ Artemis Documentation","links":{"home":"http://activemq.apache.org/","issues":"http://activemq.apache.org/","contribute":"http://activemq.apache.org/contributing.html"},"gitbook":"3.x.x","description":"ActiveMQ Artemis User Guide and Reference Documentation"},"file":{"path":"protocols-interoperability.md","mtime":"2017-03-08T02:33:12.000Z","type":"markdown"},"gitbook":{"version":"3.1.1","time":"2017-03-08T02:38:15.470Z"},"basePath":".","book":{"language":""}}); |
| }); |
| </script> |
| </div> |
| |
| |
| <script src="gitbook/gitbook.js"></script> |
| <script src="gitbook/theme.js"></script> |
| |
| |
| <script src="gitbook/gitbook-plugin-search/search-engine.js"></script> |
| |
| |
| |
| <script src="gitbook/gitbook-plugin-search/search.js"></script> |
| |
| |
| |
| <script src="gitbook/gitbook-plugin-lunr/lunr.min.js"></script> |
| |
| |
| |
| <script src="gitbook/gitbook-plugin-lunr/search-lunr.js"></script> |
| |
| |
| |
| <script src="gitbook/gitbook-plugin-sharing/buttons.js"></script> |
| |
| |
| |
| <script src="gitbook/gitbook-plugin-fontsettings/fontsettings.js"></script> |
| |
| |
| |
| </body> |
| </html> |
| |
