| |
| <!DOCTYPE HTML> |
| <html lang="" > |
| <head> |
| <title>Address Model ยท 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="protocols-interoperability.html" /> |
| |
| |
| <link rel="prev" href="upgrading.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="versions.html"> |
| |
| <a href="versions.html"> |
| |
| |
| Versions |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.6" data-path="messaging-concepts.html"> |
| |
| <a href="messaging-concepts.html"> |
| |
| |
| Messaging Concepts |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.7" data-path="architecture.html"> |
| |
| <a href="architecture.html"> |
| |
| |
| Architecture |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.8" data-path="using-server.html"> |
| |
| <a href="using-server.html"> |
| |
| |
| Using the Server |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.9" data-path="upgrading.html"> |
| |
| <a href="upgrading.html"> |
| |
| |
| Upgrading |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter active" data-level="1.10" data-path="address-model.html"> |
| |
| <a href="address-model.html"> |
| |
| |
| Address Model |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.11" data-path="protocols-interoperability.html"> |
| |
| <a href="protocols-interoperability.html"> |
| |
| |
| Protocols and Interoperability |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.12" data-path="amqp.html"> |
| |
| <a href="amqp.html"> |
| |
| |
| AMQP |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.13" data-path="mqtt.html"> |
| |
| <a href="mqtt.html"> |
| |
| |
| MQTT |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.14" data-path="stomp.html"> |
| |
| <a href="stomp.html"> |
| |
| |
| STOMP |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.15" data-path="openwire.html"> |
| |
| <a href="openwire.html"> |
| |
| |
| OpenWire |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.16" data-path="core.html"> |
| |
| <a href="core.html"> |
| |
| |
| Core |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.17" 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.18" data-path="using-jms.html"> |
| |
| <a href="using-jms.html"> |
| |
| |
| Using JMS |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.19" data-path="client-classpath.html"> |
| |
| <a href="client-classpath.html"> |
| |
| |
| The Client Classpath |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.20" data-path="examples.html"> |
| |
| <a href="examples.html"> |
| |
| |
| Examples |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.21" data-path="wildcard-routing.html"> |
| |
| <a href="wildcard-routing.html"> |
| |
| |
| Routing Messages With Wild Cards |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.22" data-path="wildcard-syntax.html"> |
| |
| <a href="wildcard-syntax.html"> |
| |
| |
| Wildcard Syntax |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.23" data-path="filter-expressions.html"> |
| |
| <a href="filter-expressions.html"> |
| |
| |
| Filter Expressions |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.24" data-path="persistence.html"> |
| |
| <a href="persistence.html"> |
| |
| |
| Persistence |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.25" data-path="configuring-transports.html"> |
| |
| <a href="configuring-transports.html"> |
| |
| |
| Configuring Transports |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.26" data-path="config-reload.html"> |
| |
| <a href="config-reload.html"> |
| |
| |
| Configuration Reload |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.27" data-path="connection-ttl.html"> |
| |
| <a href="connection-ttl.html"> |
| |
| |
| Detecting Dead Connections |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.28" data-path="slow-consumers.html"> |
| |
| <a href="slow-consumers.html"> |
| |
| |
| Detecting Slow Consumers |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.29" data-path="network-isolation.html"> |
| |
| <a href="network-isolation.html"> |
| |
| |
| Avoiding Network Isolation |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.30" data-path="critical-analysis.html"> |
| |
| <a href="critical-analysis.html"> |
| |
| |
| Detecting Broker Issues (Critical Analysis) |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.31" data-path="transaction-config.html"> |
| |
| <a href="transaction-config.html"> |
| |
| |
| Resource Manager Configuration |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.32" data-path="flow-control.html"> |
| |
| <a href="flow-control.html"> |
| |
| |
| Flow Control |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.33" data-path="send-guarantees.html"> |
| |
| <a href="send-guarantees.html"> |
| |
| |
| Guarantees of sends and commits |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.34" data-path="undelivered-messages.html"> |
| |
| <a href="undelivered-messages.html"> |
| |
| |
| Message Redelivery and Undelivered Messages |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.35" data-path="message-expiry.html"> |
| |
| <a href="message-expiry.html"> |
| |
| |
| Message Expiry |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.36" data-path="large-messages.html"> |
| |
| <a href="large-messages.html"> |
| |
| |
| Large Messages |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.37" data-path="paging.html"> |
| |
| <a href="paging.html"> |
| |
| |
| Paging |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.38" data-path="scheduled-messages.html"> |
| |
| <a href="scheduled-messages.html"> |
| |
| |
| Scheduled Messages |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.39" data-path="last-value-queues.html"> |
| |
| <a href="last-value-queues.html"> |
| |
| |
| Last-Value Queues |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.40" data-path="ring-queues.html"> |
| |
| <a href="ring-queues.html"> |
| |
| |
| Ring Queues |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.41" data-path="retroactive-addresses.html"> |
| |
| <a href="retroactive-addresses.html"> |
| |
| |
| Retroactive Addresses |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.42" data-path="exclusive-queues.html"> |
| |
| <a href="exclusive-queues.html"> |
| |
| |
| Exclusive Queues |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.43" data-path="message-grouping.html"> |
| |
| <a href="message-grouping.html"> |
| |
| |
| Message Grouping |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.44" data-path="consumer-priority.html"> |
| |
| <a href="consumer-priority.html"> |
| |
| |
| Consumer Priority |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.45" data-path="pre-acknowledge.html"> |
| |
| <a href="pre-acknowledge.html"> |
| |
| |
| Extra Acknowledge Modes |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.46" data-path="management.html"> |
| |
| <a href="management.html"> |
| |
| |
| Management |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.47" data-path="management-console.html"> |
| |
| <a href="management-console.html"> |
| |
| |
| Management Console |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.48" data-path="metrics.html"> |
| |
| <a href="metrics.html"> |
| |
| |
| Metrics |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.49" data-path="security.html"> |
| |
| <a href="security.html"> |
| |
| |
| Security |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.50" data-path="masking-passwords.html"> |
| |
| <a href="masking-passwords.html"> |
| |
| |
| Masking Passwords |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.51" data-path="broker-plugins.html"> |
| |
| <a href="broker-plugins.html"> |
| |
| |
| Broker Plugins |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.52" data-path="resource-limits.html"> |
| |
| <a href="resource-limits.html"> |
| |
| |
| Resource Limits |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.53" data-path="jms-bridge.html"> |
| |
| <a href="jms-bridge.html"> |
| |
| |
| The JMS Bridge |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.54" data-path="client-reconnection.html"> |
| |
| <a href="client-reconnection.html"> |
| |
| |
| Client Reconnection and Session Reattachment |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.55" data-path="diverts.html"> |
| |
| <a href="diverts.html"> |
| |
| |
| Diverting and Splitting Message Flows |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.56" data-path="core-bridges.html"> |
| |
| <a href="core-bridges.html"> |
| |
| |
| Core Bridges |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.57" data-path="transformers.html"> |
| |
| <a href="transformers.html"> |
| |
| |
| Transformers |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.58" data-path="duplicate-detection.html"> |
| |
| <a href="duplicate-detection.html"> |
| |
| |
| Duplicate Message Detection |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.59" data-path="clusters.html"> |
| |
| <a href="clusters.html"> |
| |
| |
| Clusters |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.60" data-path="federation.html"> |
| |
| <a href="federation.html"> |
| |
| |
| Federation |
| |
| </a> |
| |
| |
| |
| <ul class="articles"> |
| |
| |
| <li class="chapter " data-level="1.60.1" data-path="federation-address.html"> |
| |
| <a href="federation-address.html"> |
| |
| |
| Address Federation |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.60.2" data-path="federation-queue.html"> |
| |
| <a href="federation-queue.html"> |
| |
| |
| Queue Federation |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| |
| </ul> |
| |
| </li> |
| |
| <li class="chapter " data-level="1.61" data-path="ha.html"> |
| |
| <a href="ha.html"> |
| |
| |
| High Availability and Failover |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.62" data-path="graceful-shutdown.html"> |
| |
| <a href="graceful-shutdown.html"> |
| |
| |
| Graceful Server Shutdown |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.63" data-path="libaio.html"> |
| |
| <a href="libaio.html"> |
| |
| |
| Libaio Native Libraries |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.64" data-path="thread-pooling.html"> |
| |
| <a href="thread-pooling.html"> |
| |
| |
| Thread management |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.65" data-path="web-server.html"> |
| |
| <a href="web-server.html"> |
| |
| |
| Embedded Web Server |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.66" data-path="logging.html"> |
| |
| <a href="logging.html"> |
| |
| |
| Logging |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.67" data-path="rest.html"> |
| |
| <a href="rest.html"> |
| |
| |
| REST Interface |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.68" data-path="embedding-activemq.html"> |
| |
| <a href="embedding-activemq.html"> |
| |
| |
| Embedding the Broker |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.69" data-path="karaf.html"> |
| |
| <a href="karaf.html"> |
| |
| |
| Apache Karaf |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.70" data-path="tomcat.html"> |
| |
| <a href="tomcat.html"> |
| |
| |
| Apache Tomcat |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.71" data-path="spring-integration.html"> |
| |
| <a href="spring-integration.html"> |
| |
| |
| Spring Integration |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.72" data-path="cdi-integration.html"> |
| |
| <a href="cdi-integration.html"> |
| |
| |
| CDI Integration |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.73" data-path="intercepting-operations.html"> |
| |
| <a href="intercepting-operations.html"> |
| |
| |
| Intercepting Operations |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.74" data-path="data-tools.html"> |
| |
| <a href="data-tools.html"> |
| |
| |
| Data Tools |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.75" data-path="maven-plugin.html"> |
| |
| <a href="maven-plugin.html"> |
| |
| |
| Maven Plugin |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.76" data-path="unit-testing.html"> |
| |
| <a href="unit-testing.html"> |
| |
| |
| Unit Testing |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.77" data-path="perf-tuning.html"> |
| |
| <a href="perf-tuning.html"> |
| |
| |
| Troubleshooting and Performance Tuning |
| |
| </a> |
| |
| |
| |
| </li> |
| |
| <li class="chapter " data-level="1.78" 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="." >Address Model</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="addressing-model">Addressing Model</h1> |
| <p>Apache ActiveMQ Artemis has a unique addressing model that is both powerful and |
| flexible and that offers great performance. The addressing model comprises |
| three main concepts: <strong>addresses</strong>, <strong>queues</strong>, and <strong>routing types</strong>.</p> |
| <h3 id="address">Address</h3> |
| <p>An address represents a messaging endpoint. Within the configuration, a typical |
| address is given a unique name, 0 or more queues, and a routing type.</p> |
| <h3 id="queue">Queue</h3> |
| <p>A queue is associated with an address. There can be multiple queues per |
| address. Once an incoming message is matched to an address, the message will be |
| sent on to one or more of its queues, depending on the routing type configured. |
| Queues can be configured to be automatically created and deleted.</p> |
| <h3 id="routing-types">Routing Types</h3> |
| <p>A routing type determines how messages are sent to the queues associated with |
| an address. An Apache ActiveMQ Artemis address can be configured with two |
| different routing types.</p> |
| <p>Table 1. Routing Types</p> |
| <table> |
| <thead> |
| <tr> |
| <th>If you want your messages routed to...</th> |
| <th>Use this routing type...</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td>A single queue within the matching address, in a point-to-point manner.</td> |
| <td>Anycast</td> |
| </tr> |
| <tr> |
| <td>Every queue within the matching address, in a publish-subscribe manner.</td> |
| <td>Multicast</td> |
| </tr> |
| </tbody> |
| </table> |
| <p><strong>Note:</strong> It is possible to define more than one routing type per address, but |
| this typically results in an anti-pattern and is therefore not recommended. If |
| an address does use both routing types, however, and the client does not show a |
| preference for either one, the broker typically defaults to the anycast routing |
| type.</p> |
| <p>The one exception is when the client uses the MQTT protocol. In that case, the |
| default routing type is multicast.</p> |
| <p>For additional details about these concepts refer to <a href="core.html">the core</a> chapter.</p> |
| <h2 id="basic-address-configuration">Basic Address Configuration</h2> |
| <p>The following examples show how to configure basic point to point and publish |
| subscribe addresses.</p> |
| <h3 id="point-to-point-messaging">Point-to-Point Messaging</h3> |
| <p>Point-to-point messaging is a common scenario in which a message sent by a |
| producer has only one consumer. AMQP and JMS message producers and consumers |
| can make use of point-to-point messaging queues, for example. Define an anycast |
| routing type for an address so that its queues receive messages in a |
| point-to-point manner.</p> |
| <p>When a message is received on an address using anycast, Apache ActiveMQ Artemis |
| locates the queue associated with the address and routes the message to it. |
| When consumers request to consume from the address, the broker locates the |
| relevant queue and associates this queue with the appropriate consumers. If |
| multiple consumers are connected to the same queue, messages are distributed |
| amongst each consumer equally, providing the consumers are equally able to |
| handle them.</p> |
| <p><img src="images/addressing-model-p2p.png" alt="Point to Point"> |
| Figure 1. Point to Point Messaging</p> |
| <h4 id="using-the-anycast-routing-type">Using the Anycast Routing Type</h4> |
| <p>Open the file <code><broker-instance>/etc/broker.xml</code> for editing.</p> |
| <p>Add an address configuration element and its associated queue if they do not |
| exist already.</p> |
| <p><strong>Note:</strong> For normal Point to Point semantics, the queue name <strong>MUST</strong> match the |
| address name.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">address</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"orders"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">anycast</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">queue</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"orders"</span>/></span> |
| <span class="hljs-tag"></<span class="hljs-name">anycast</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">address</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">addresses</span>></span> |
| </code></pre> |
| <h3 id="publish-subscribe-messaging">Publish-Subscribe Messaging</h3> |
| <p>In a publish-subscribe scenario, messages are sent to every consumer subscribed |
| to an address. JMS topics and MQTT subscriptions are two examples of |
| publish-subscribe messaging.</p> |
| <p>To configure an address with publish-subscribe semantics, create an address |
| with the multicast routing type.</p> |
| <p><img src="images/addressing-model-pubsub.png" alt="Publish Subscribe"> |
| Figure 2. Publish-Subscribe</p> |
| <h4 id="using-the-multicast-routing-type">Using the Multicast Routing Type</h4> |
| <p>Open the file <code><broker-instance>/etc/broker.xml</code> for editing.</p> |
| <p>Add an address configuration element with multicast routing type.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">address</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"pubsub.foo"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">multicast</span>/></span> |
| <span class="hljs-tag"></<span class="hljs-name">address</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">addresses</span>></span> |
| </code></pre> |
| <p>When clients connect to an address with the multicast element, a subscription |
| queue for the client will be automatically created for the client. It is also |
| possible to pre-configure subscription queues and connect to them directly |
| using the queue's <a href="#fully-qualified-queue-names">Fully Qualified Queue names</a>.</p> |
| <p>Optionally add one or more queue elements to the address and wrap the multicast |
| element around them. This step is typically not needed since the broker will |
| automatically create a queue for each subscription requested by a client.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">address</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"pubsub.foo"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">multicast</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">queue</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"client123.pubsub.foo"</span>/></span> |
| <span class="hljs-tag"><<span class="hljs-name">queue</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"client456.pubsub.foo"</span>/></span> |
| <span class="hljs-tag"></<span class="hljs-name">multicast</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">address</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">addresses</span>></span> |
| </code></pre> |
| <p>Figure 3. Point-to-Point with Two Queues</p> |
| <h3 id="point-to-point-address-multiple-queues">Point-to-Point Address multiple Queues</h3> |
| <p>It is actually possible to define more than one queue on an address with an |
| anycast routing type. When messages are received on such an address, they are |
| firstly distributed evenly across all the defined queues. Using <a href="#fully-qualified-queue-names">Fully |
| Qualified Queue names</a>, clients are able to |
| select the queue that they would like to subscribe to. Should more than one |
| consumer connect directly to a single queue, Apache ActiveMQ Artemis will take |
| care of distributing messages between them, as in the example above.</p> |
| <p><img src="images/addressing-model-p2p2.png" alt="Point to Point"> |
| Figure 3. Point-to-Point with Two Queues</p> |
| <p><strong>Note:</strong> This is how Apache ActiveMQ Artemis handles load balancing of queues |
| across multiple nodes in a cluster. Configuring a Point-to-Point Address with |
| two queues, open the file <code><broker-instance>/etc/broker.xml</code> for editing.</p> |
| <p>Add an address configuration with Anycast routing type element and its |
| associated queues.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">address</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"address.foo"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">anycast</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">queue</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"q1"</span>/></span> |
| <span class="hljs-tag"><<span class="hljs-name">queue</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"q2"</span>/></span> |
| <span class="hljs-tag"></<span class="hljs-name">anycast</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">address</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">addresses</span>></span> |
| </code></pre> |
| <h3 id="point-to-point-and-publish-subscribe-addresses">Point-to-Point and Publish-Subscribe Addresses</h3> |
| <p>It is possible to define an address with both point-to-point and |
| publish-subscribe semantics enabled. While not typically recommend, this can be |
| useful when you want, for example, a JMS Queue say orders and a JMS Topic named |
| orders. The different routing types make the addresses appear to be distinct.</p> |
| <p>Using an example of JMS Clients, the messages sent by a JMS message producer |
| will be routed using the anycast routing type. Messages sent by a JMS topic |
| producer will use the multicast routing type. In addition when a JMS topic |
| consumer attaches, it will be attached to it’s own subscription queue. JMS |
| queue consumer will be attached to the anycast queue.</p> |
| <p><img src="images/addressing-model-p2p-pubsub.png" alt="Point to Point"> |
| Figure 4. Point-to-Point and Publish-Subscribe</p> |
| <p><strong>Note:</strong> The behavior in this scenario is dependent on the protocol being |
| used. For JMS there is a clear distinction between topic and queue producers |
| and consumers, which make the logic straight forward. Other protocols like AMQP |
| do not make this distinction. A message being sent via AMQP will be routed by |
| both anycast and multicast and consumers will default to anycast. For more |
| information, please check the behavior of each protocol in the sections on |
| protocols.</p> |
| <p>The XML snippet below is an example of what the configuration for an address |
| using both anycast and multicast would look like in |
| <code><broker-instance>/etc/broker.xml</code>. Note that subscription queues are typically |
| created on demand, so there is no need to list specific queue elements inside |
| the multicast routing type.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">address</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"foo.orders"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">anycast</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">queue</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"orders"</span>/></span> |
| <span class="hljs-tag"></<span class="hljs-name">anycast</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">multicast</span>/></span> |
| <span class="hljs-tag"></<span class="hljs-name">address</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">addresses</span>></span> |
| </code></pre> |
| <h2 id="how-to-filter-messages">How to filter messages</h2> |
| <p>Apache ActiveMQ Artemis supports the ability to filter messages using Apache |
| Artemis <a href="filter-expressions.html">Filter Expressions</a>.</p> |
| <p>Filters can be applied in two places, on a queue and on a consumer.</p> |
| <h3 id="queue-filter">Queue Filter</h3> |
| <p>When a filter is applied to a queue, messages are filtered before they are sent to |
| the queue. To add a queue filter use the filter element when configuring a |
| queue. Open up <code><broker-instance>/etc/broker.xml</code> and add an address with a |
| queue, using the filter element to configure a filter on this queue.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">address</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"filter"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">queue</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"filter"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">filter</span> <span class="hljs-attr">string</span>=<span class="hljs-string">"color='red'"</span>/></span> |
| <span class="hljs-tag"></<span class="hljs-name">queue</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">address</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">addresses</span>></span> |
| </code></pre> |
| <p>The filter defined above ensures that only messages with an attribute |
| <code>"color='red'"</code> is sent to this queue.</p> |
| <h3 id="consumer-filters">Consumer Filters</h3> |
| <p>Consumer filters are applied after messages have reached a queue and are |
| defined using the appropriate client APIs. The following JMS example shows how |
| consumer filters work.</p> |
| <ol> |
| <li>Define an address with a single queue, with no filter applied.</li> |
| </ol> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">address</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"filter"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">queue</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"filter"</span>/></span> |
| <span class="hljs-tag"></<span class="hljs-name">address</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">addresses</span>></span> |
| </code></pre> |
| <pre><code class="lang-java">... |
| <span class="hljs-comment">// Send some messages</span> |
| <span class="hljs-keyword">for</span> (<span class="hljs-keyword">int</span> i = <span class="hljs-number">0</span>; i < <span class="hljs-number">3</span>; i ++) { |
| TextMessage redMessage = senderSession.createTextMessage(<span class="hljs-string">"Red"</span>); |
| redMessage.setStringProperty(<span class="hljs-string">"color"</span>, <span class="hljs-string">"red"</span>); |
| producer.send(redMessage) |
| |
| TextMessage greenMessage = senderSession.createTextMessage(<span class="hljs-string">"Green"</span>); |
| greenMessage.setStringProperty(<span class="hljs-string">"color"</span>, <span class="hljs-string">"green"</span>); |
| producer.send(greenMessage) |
| } |
| </code></pre> |
| <p>At this point the queue would have 6 messages: red,green,red,green,red,green</p> |
| <pre><code class="lang-java">MessageConsumer redConsumer = redSession.createConsumer(queue, <span class="hljs-string">"color='red'"</span>); |
| </code></pre> |
| <p>The redConsumer has a filter that only matches "red" messages. The redConsumer |
| will receive 3 messages.</p> |
| <pre><code>red, red, red |
| </code></pre><p>The resulting queue would now be</p> |
| <pre><code>green, green, green |
| </code></pre><h2 id="automatic-addressqueue-management">Automatic Address/Queue Management</h2> |
| <p>You can configure Apache ActiveMQ Artemis to automatically create addresses and |
| queues, and then delete them when they are no longer in use. This saves you |
| from having to preconfigure each address and queue before a client can connect |
| to it. Automatic creation and deletion is configured on a per address basis and |
| is controlled by following:</p> |
| <table> |
| <thead> |
| <tr> |
| <th>Parameter</th> |
| <th>Description</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td><code>auto-create-addresses</code></td> |
| <td>When set to true, the broker will create the address requested by the client if it does not exist already. The default is <code>true</code>.</td> |
| </tr> |
| <tr> |
| <td><code>auto-delete-addresses</code></td> |
| <td>When set to true, the broker will be delete any <strong>auto-created</strong> adddress once all of it’s queues have been deleted. The default is <code>true</code></td> |
| </tr> |
| <tr> |
| <td><code>default-address-routing-type</code></td> |
| <td>The routing type to use if the client does not specify one. Possible values are <code>MULTICAST</code> and <code>ANYCAST</code>. See earlier in this chapter for more information about routing types. The default value is <code>MULTICAST</code>.</td> |
| </tr> |
| </tbody> |
| </table> |
| <h3 id="auto-address-creation">Auto Address Creation</h3> |
| <ul> |
| <li><p>Edit the file <code><broker-instance>/etc/broker.xml</code> and add the |
| <code>auto-create-addresses</code> element to the <code>address-setting</code> you want the broker |
| to automatically create.</p> |
| </li> |
| <li><p>(Optional) Add the <code>address-setting</code> if it does not exist. Use the match |
| parameter and the <a href="wildcard-syntax.html">wildcard syntax</a> to match more than |
| one specific address.</p> |
| </li> |
| <li><p>Set <code>auto-create-addresses</code> to <code>true</code></p> |
| </li> |
| <li><p>(Optional) Assign <code>MULTICAST</code> or <code>ANYCAST</code> as the default routing type for |
| the address.</p> |
| </li> |
| </ul> |
| <p>The example below configures an <code>address-setting</code> to be automatically created |
| by the broker. The default routing type to be used if not specified by the |
| client is MULTICAST. Note that wildcard syntax is used. Any address starting |
| with <code>/news/politics/</code> will be automatically created by the broker.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">address-setting</span> <span class="hljs-attr">match</span>=<span class="hljs-string">"/news/politics/#"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-create-addresses</span>></span>true<span class="hljs-tag"></<span class="hljs-name">auto-create-addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">default-address-routing-type</span>></span>MULTICAST<span class="hljs-tag"></<span class="hljs-name">default-address-routing-type</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">address-setting</span>></span> |
| </code></pre> |
| <h3 id="auto-address-deletion">Auto Address Deletion</h3> |
| <ul> |
| <li><p>Edit the file <code><broker-instance>/etc/broker.xml</code> and add the |
| <code>auto-delete-addresses</code> element to the <code>address-setting</code> you want the broker to |
| automatically create.</p> |
| </li> |
| <li><p>(Optional) Add the <code>address-setting</code> if it does not exist. Use the match |
| parameter and the <a href="wildcard-syntax.html">wildcard syntax</a> to match more than one |
| specific address.</p> |
| </li> |
| <li><p>Set <code>auto-delete-addresses</code> to <code>true</code></p> |
| </li> |
| </ul> |
| <p>The example below configures an <code>address-setting</code> to be automatically deleted |
| by the broker. Note that wildcard syntax is used. Any address request by the |
| client that starts with <code>/news/politics/</code> is configured to be automatically |
| deleted by the broker.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">address-setting</span> <span class="hljs-attr">match</span>=<span class="hljs-string">"/news/politics/#"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-delete-addresses</span>></span>true<span class="hljs-tag"></<span class="hljs-name">auto-delete-addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">default-address-routing-type</span>></span>MULTICAST<span class="hljs-tag"></<span class="hljs-name">default-address-routing-type</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">address-setting</span>></span> |
| </code></pre> |
| <h2 id="fully-qualified-queue-names">"Fully Qualified" Queue Names</h2> |
| <p>Internally the broker maps a client’s request for an address to specific |
| queues. The broker decides on behalf of the client which queues to send |
| messages to or from which queue to receive messages. However, more advanced use |
| cases might require that the client specify a queue directly. In these |
| situations the client uses a fully qualified queue name, by specifying both |
| the address name and the queue name, separated by a ::.</p> |
| <p>Currently Artemis supports fully qualified queue names on Core, AMQP, JMS, |
| OpenWire, MQTT and STOMP protocols for receiving messages only.</p> |
| <h3 id="specifying-a-fully-qualified-queue-name">Specifying a Fully Qualified Queue Name</h3> |
| <p>In this example, the address foo is configured with two queues q1, q2 as shown |
| in the configuration below.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">address</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"foo"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">anycast</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">queue</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"q1"</span> /></span> |
| <span class="hljs-tag"><<span class="hljs-name">queue</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"q2"</span> /></span> |
| <span class="hljs-tag"></<span class="hljs-name">anycast</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">address</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">addresses</span>></span> |
| </code></pre> |
| <p>In the client code, use both the address name and the queue name when |
| requesting a connection from the broker. Remember to use two colons, <code>::</code>, to |
| separate the names, as in the example Java code below.</p> |
| <pre><code class="lang-java">String FQQN = <span class="hljs-string">"foo::q1"</span>; |
| Queue q1 session.createQueue(FQQN); |
| MessageConsumer consumer = session.createConsumer(q1); |
| </code></pre> |
| <h2 id="using-prefixes-to-determine-routing-type">Using Prefixes to Determine Routing Type</h2> |
| <p>Normally, if the broker receives a message sent to a particular address, that |
| has both <code>ANYCAST</code> and <code>MULTICAST</code> routing types enable, it will route a copy |
| of the message to <strong>one</strong> of the <code>ANYCAST</code> queues and to <strong>all</strong> of the |
| <code>MULTICAST</code> queues.</p> |
| <p>However, clients can specify a special prefix when connecting to an address to |
| indicate which kind of routing type to use. The prefixes are custom values that |
| are designated using the anycastPrefix and multicastPrefix parameters within |
| the URL of an acceptor.</p> |
| <h3 id="configuring-an-anycast-prefix">Configuring an Anycast Prefix</h3> |
| <p>In <code><broker-instance>/etc/broker.xml</code>, add the <code>anycastPrefix</code> to the URL of |
| the desired acceptor. In the example below, the acceptor is configured to use |
| <code>anycast://</code> for the <code>anycastPrefix</code>. Client code can specify <code>anycast://foo/</code> |
| if the client needs to send a message to only one of the <code>ANYCAST</code> queues.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">acceptor</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"artemis"</span>></span>tcp://0.0.0.0:61616?protocols=AMQP;anycastPrefix=anycast://<span class="hljs-tag"></<span class="hljs-name">acceptor</span>></span> |
| </code></pre> |
| <h3 id="configuring-a-multicast-prefix">Configuring a Multicast Prefix</h3> |
| <p>In <code><broker-instance>/etc/broker.xml</code>, add the <code>multicastPrefix</code> to the URL of |
| the desired acceptor. In the example below, the acceptor is configured to use |
| <code>multicast://</code> for the <code>multicastPrefix</code>. Client code can specify |
| <code>multicast://foo/</code> if the client needs to send a message to only one of the |
| <code>MULTICAST</code> queues.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">acceptor</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"artemis"</span>></span>tcp://0.0.0.0:61616?protocols=AMQP;multicastPrefix=multicast://<span class="hljs-tag"></<span class="hljs-name">acceptor</span>></span> |
| </code></pre> |
| <h2 id="advanced-address-configuration">Advanced Address Configuration</h2> |
| <h3 id="static-subscription-queues">Static Subscription Queues</h3> |
| <p>In most cases it’s not necessary to statically configure subscription queues. |
| The relevant protocol managers take care of dynamically creating subscription |
| queues when clients request to subscribe to an address. The type of |
| subscription queue created depends on what properties the client request. For |
| example, durable, non-shared, shared etc. Protocol managers use special queue |
| naming conventions to identify which queues belong to which consumers and users |
| need not worry about the details.</p> |
| <p>However, there are scenarios where a user may want to use broker side |
| configuration to statically configure a subscription and later connect to that |
| queue directly using a <a href="#fully-qualified-queue-names">Fully Qualified Queue |
| name</a>. The examples below show how to use broker |
| side configuration to statically configure a queue with publish subscribe |
| behavior for shared, non-shared, durable and non-durable subscription behavior.</p> |
| <h4 id="shared-durable-subscription-queue-using-max-consumers">Shared, Durable Subscription Queue using max-consumers</h4> |
| <p>The default behavior for queues is to not limit the number connected queue |
| consumers. The <strong>max-consumers</strong> parameter of the queue element can be used to |
| limit the number of connected consumers allowed at any one time.</p> |
| <p>Open the file <code><broker-instance>/etc/broker.xml</code> for editing.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">address</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"durable.foo"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">multicast</span>></span> |
| <span class="hljs-comment"><!-- pre-configured shared durable subscription queue --></span> |
| <span class="hljs-tag"><<span class="hljs-name">queue</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"q1"</span> <span class="hljs-attr">max-consumers</span>=<span class="hljs-string">"10"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">durable</span>></span>true<span class="hljs-tag"></<span class="hljs-name">durable</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">queue</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">multicast</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">address</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">addresses</span>></span> |
| </code></pre> |
| <h4 id="non-shared-durable-subscription-queue">Non-shared, Durable Subscription Queue</h4> |
| <p>The broker can be configured to prevent more than one consumer from connecting |
| to a queue at any one time. The subscriptions to queues configured this way are |
| therefore "non-shared". To do this simply set the <strong>max-consumers</strong> parameter |
| to <code>1</code>:</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">address</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"durable.foo"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">multicast</span>></span> |
| <span class="hljs-comment"><!-- pre-configured non shared durable subscription queue --></span> |
| <span class="hljs-tag"><<span class="hljs-name">queue</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"q1"</span> <span class="hljs-attr">max-consumers</span>=<span class="hljs-string">"1"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">durable</span>></span>true<span class="hljs-tag"></<span class="hljs-name">durable</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">queue</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">multicast</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">address</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">addresses</span>></span> |
| </code></pre> |
| <h4 id="non-durable-subscription-queue">Non-durable Subscription Queue</h4> |
| <p>Non-durable subscriptions are again usually managed by the relevant protocol |
| manager, by creating and deleting temporary queues.</p> |
| <p>If a user requires to pre-create a queue that behaves like a non-durable |
| subscription queue the <strong>purge-on-no-consumers</strong> flag can be enabled on the |
| queue. When <strong>purge-on-no-consumers</strong> is set to <strong>true</strong>. The queue will not |
| start receiving messages until a consumer is attached. When the last consumer |
| is detached from the queue. The queue is purged (its messages are removed) |
| and will not receive any more messages until a new consumer is attached.</p> |
| <p>Open the file <code><broker-instance>/etc/broker.xml</code> for editing.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">address</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"non.shared.durable.foo"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">multicast</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">queue</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"orders1"</span> <span class="hljs-attr">purge-on-no-consumers</span>=<span class="hljs-string">"true"</span>/></span> |
| <span class="hljs-tag"></<span class="hljs-name">multicast</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">address</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">addresses</span>></span> |
| </code></pre> |
| <h4 id="exclusive-consumer-queue">Exclusive Consumer Queue</h4> |
| <p>If a user requires to statically configure a queue that routes exclusively to |
| one active consumer the <strong>exclusive</strong> flag can be enabled on the queue.</p> |
| <p>When <strong>exclusive</strong> is set to <strong>true</strong> the queue will route messages to the a |
| single active consumer. When the active consumer that is being routed to is |
| detached from the queue, if another active consumer exist, one will be chosen |
| and routing will now be exclusive to it.</p> |
| <p>See <a href="exclusive-queues.html">Exclusive Queue</a> for further information.</p> |
| <p>Open the file <code><broker-instance>/etc/broker.xml</code> for editing.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">address</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"foo.bar"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">multicast</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">queue</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"orders1"</span> <span class="hljs-attr">exclusive</span>=<span class="hljs-string">"true"</span>/></span> |
| <span class="hljs-tag"></<span class="hljs-name">multicast</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">address</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">addresses</span>></span> |
| </code></pre> |
| <h2 id="protocol-managers">Protocol Managers</h2> |
| <p>A "protocol manager" maps protocol-specific concepts down to the core |
| addressing model (using addresses, queues and routing types). For example, when |
| a client sends a MQTT subscription packet with the addresses: </p> |
| <pre><code>/house/room1/lights |
| /house/room2/lights |
| </code></pre><p>The MQTT protocol manager understands that the two addresses require |
| <code>MULTICAST</code> semantics. The protocol manager will therefore first look to ensure |
| that <code>MULTICAST</code> is enabled for both addresses. If not, it will attempt to |
| dynamically create them. If successful, the protocol manager will then create |
| special subscription queues with special names, for each subscription requested |
| by the client.</p> |
| <p>The special name allows the protocol manager to quickly identify the required |
| client subscription queues should the client disconnect and reconnect at a |
| later date. If the subscription is temporary the protocol manager will delete |
| the queue once the client disconnects.</p> |
| <p>When a client requests to subscribe to a point to point address. The protocol |
| manager will look up the queue associated with the point to point address. |
| This queue should have the same name as the addresss.</p> |
| <p><strong>Note:</strong> If the queue is auto created, it will be auto deleted once there are |
| no consumers and no messages in it. For more information on auto create see |
| the next section <a href="#configuring-addresses-and-queues-via-address-settings">Configuring Addresses and Queues via Address |
| Settings</a></p> |
| <h2 id="configuring-addresses-and-queues-via-address-settings">Configuring Addresses and Queues via Address Settings</h2> |
| <p>There are some attributes that are defined against an address wildcard rather |
| than a specific address/queue. Here an example of an <code>address-setting</code> entry |
| that would be found in the <code>broker.xml</code> file.</p> |
| <pre><code class="lang-xml"><span class="hljs-tag"><<span class="hljs-name">address-settings</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">address-setting</span> <span class="hljs-attr">match</span>=<span class="hljs-string">"order.foo"</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">dead-letter-address</span>></span>DLA<span class="hljs-tag"></<span class="hljs-name">dead-letter-address</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-create-dead-letter-resources</span>></span>false<span class="hljs-tag"></<span class="hljs-name">auto-create-dead-letter-resources</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">dead-letter-queue-prefix</span>></span>DLQ.<span class="hljs-tag"></<span class="hljs-name">dead-letter-queue-prefix</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">dead-letter-queue-suffix</span>></span><span class="hljs-tag"></<span class="hljs-name">dead-letter-queue-suffix</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">expiry-address</span>></span>ExpiryQueue<span class="hljs-tag"></<span class="hljs-name">expiry-address</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-create-expiry-resources</span>></span>false<span class="hljs-tag"></<span class="hljs-name">auto-create-expiry-resources</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">expiry-queue-prefix</span>></span>EXP.<span class="hljs-tag"></<span class="hljs-name">expiry-queue-prefix</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">expiry-queue-suffix</span>></span><span class="hljs-tag"></<span class="hljs-name">expiry-queue-suffix</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">expiry-delay</span>></span>123<span class="hljs-tag"></<span class="hljs-name">expiry-delay</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">redelivery-delay</span>></span>5000<span class="hljs-tag"></<span class="hljs-name">redelivery-delay</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">redelivery-delay-multiplier</span>></span>1.0<span class="hljs-tag"></<span class="hljs-name">redelivery-delay-multiplier</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">redelivery-collision-avoidance-factor</span>></span>0.0<span class="hljs-tag"></<span class="hljs-name">redelivery-collision-avoidance-factor</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">max-redelivery-delay</span>></span>10000<span class="hljs-tag"></<span class="hljs-name">max-redelivery-delay</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">max-delivery-attempts</span>></span>3<span class="hljs-tag"></<span class="hljs-name">max-delivery-attempts</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">max-size-bytes</span>></span>100000<span class="hljs-tag"></<span class="hljs-name">max-size-bytes</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">max-size-bytes-reject-threshold</span>></span>-1<span class="hljs-tag"></<span class="hljs-name">max-size-bytes-reject-threshold</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">page-size-bytes</span>></span>20000<span class="hljs-tag"></<span class="hljs-name">page-size-bytes</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">page-max-cache-size</span>></span><span class="hljs-tag"></<span class="hljs-name">page-max-cache-size</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">address-full-policy</span>></span>PAGE<span class="hljs-tag"></<span class="hljs-name">address-full-policy</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">message-counter-history-day-limit</span>></span><span class="hljs-tag"></<span class="hljs-name">message-counter-history-day-limit</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">last-value-queue</span>></span>true<span class="hljs-tag"></<span class="hljs-name">last-value-queue</span>></span> <span class="hljs-comment"><!-- deprecated! see default-last-value-queue --></span> |
| <span class="hljs-tag"><<span class="hljs-name">default-last-value-queue</span>></span>false<span class="hljs-tag"></<span class="hljs-name">default-last-value-queue</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">default-non-destructive</span>></span>false<span class="hljs-tag"></<span class="hljs-name">default-non-destructive</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">default-exclusive-queue</span>></span>false<span class="hljs-tag"></<span class="hljs-name">default-exclusive-queue</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">default-consumers-before-dispatch</span>></span>0<span class="hljs-tag"></<span class="hljs-name">default-consumers-before-dispatch</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">default-delay-before-dispatch</span>></span>-1<span class="hljs-tag"></<span class="hljs-name">default-delay-before-dispatch</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">redistribution-delay</span>></span>0<span class="hljs-tag"></<span class="hljs-name">redistribution-delay</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">send-to-dla-on-no-route</span>></span>true<span class="hljs-tag"></<span class="hljs-name">send-to-dla-on-no-route</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">slow-consumer-threshold</span>></span>-1<span class="hljs-tag"></<span class="hljs-name">slow-consumer-threshold</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">slow-consumer-policy</span>></span>NOTIFY<span class="hljs-tag"></<span class="hljs-name">slow-consumer-policy</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">slow-consumer-check-period</span>></span>5<span class="hljs-tag"></<span class="hljs-name">slow-consumer-check-period</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-create-jms-queues</span>></span>true<span class="hljs-tag"></<span class="hljs-name">auto-create-jms-queues</span>></span> <span class="hljs-comment"><!-- deprecated! see auto-create-queues --></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-delete-jms-queues</span>></span>true<span class="hljs-tag"></<span class="hljs-name">auto-delete-jms-queues</span>></span> <span class="hljs-comment"><!-- deprecated! see auto-delete-queues --></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-create-jms-topics</span>></span>true<span class="hljs-tag"></<span class="hljs-name">auto-create-jms-topics</span>></span> <span class="hljs-comment"><!-- deprecated! see auto-create-addresses --></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-delete-jms-topics</span>></span>true<span class="hljs-tag"></<span class="hljs-name">auto-delete-jms-topics</span>></span> <span class="hljs-comment"><!-- deprecated! see auto-delete-addresses --></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-create-queues</span>></span>true<span class="hljs-tag"></<span class="hljs-name">auto-create-queues</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-delete-queues</span>></span>true<span class="hljs-tag"></<span class="hljs-name">auto-delete-queues</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-delete-created-queues</span>></span>false<span class="hljs-tag"></<span class="hljs-name">auto-delete-created-queues</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-delete-queues-delay</span>></span>0<span class="hljs-tag"></<span class="hljs-name">auto-delete-queues-delay</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-delete-queues-message-count</span>></span>0<span class="hljs-tag"></<span class="hljs-name">auto-delete-queues-message-count</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">config-delete-queues</span>></span>OFF<span class="hljs-tag"></<span class="hljs-name">config-delete-queues</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-create-addresses</span>></span>true<span class="hljs-tag"></<span class="hljs-name">auto-create-addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-delete-addresses</span>></span>true<span class="hljs-tag"></<span class="hljs-name">auto-delete-addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">auto-delete-addresses-delay</span>></span>0<span class="hljs-tag"></<span class="hljs-name">auto-delete-addresses-delay</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">config-delete-addresses</span>></span>OFF<span class="hljs-tag"></<span class="hljs-name">config-delete-addresses</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">management-browse-page-size</span>></span>200<span class="hljs-tag"></<span class="hljs-name">management-browse-page-size</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">default-purge-on-no-consumers</span>></span>false<span class="hljs-tag"></<span class="hljs-name">default-purge-on-no-consumers</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">default-max-consumers</span>></span>-1<span class="hljs-tag"></<span class="hljs-name">default-max-consumers</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">default-queue-routing-type</span>></span><span class="hljs-tag"></<span class="hljs-name">default-queue-routing-type</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">default-address-routing-type</span>></span><span class="hljs-tag"></<span class="hljs-name">default-address-routing-type</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">default-ring-size</span>></span>-1<span class="hljs-tag"></<span class="hljs-name">default-ring-size</span>></span> |
| <span class="hljs-tag"><<span class="hljs-name">retroactive-message-count</span>></span>0<span class="hljs-tag"></<span class="hljs-name">retroactive-message-count</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">address-setting</span>></span> |
| <span class="hljs-tag"></<span class="hljs-name">address-settings</span>></span> |
| </code></pre> |
| <p>The idea with address settings, is you can provide a block of settings which |
| will be applied against any addresses that match the string in the <code>match</code> |
| attribute. In the above example the settings would only be applied to the |
| address "order.foo" address but you can also use |
| <a href="wildcard-syntax.html">wildcards</a> to apply settings.</p> |
| <p>For example, if you used the <code>match</code> string <code>queue.#</code> the settings would be |
| applied to all addresses which start with <code>queue.</code></p> |
| <p>The meaning of the specific settings are explained fully throughout the user |
| manual, however here is a brief description with a link to the appropriate |
| chapter if available.</p> |
| <p><code>dead-letter-address</code> is the address to which messages are sent when they |
| exceed <code>max-delivery-attempts</code>. If no address is defined here then such |
| messages will simply be discarded. Read more about <a href="undelivered-messages.html#configuring-dead-letter-addresses">undelivered |
| messages</a>.</p> |
| <p><code>auto-create-dead-letter-resources</code> determines whether or not the broker will |
| automatically create the defined <code>dead-letter-address</code> and a corresponding |
| dead-letter queue when a message is undeliverable. Read more in the chapter |
| about <a href="undelivered-messages.html">undelivered messages</a>.</p> |
| <p><code>dead-letter-queue-prefix</code> defines the prefix used for automatically created |
| dead-letter queues. Read more in the chapter about |
| <a href="undelivered-messages.html">undelivered messages</a>.</p> |
| <p><code>dead-letter-queue-suffix</code> defines the suffix used for automatically created |
| dead-letter queues. Read more in the chapter about |
| <a href="undelivered-messages.html">undelivered messages</a>.</p> |
| <p><code>expiry-address</code> defines where to send a message that has expired. If no |
| address is defined here then such messages will simply be discarded. Read more |
| about <a href="message-expiry.html#configuring-expiry-addresses">message expiry</a>.</p> |
| <p><code>auto-create-expiry-resources</code> determines whether or not the broker will |
| automatically create the defined <code>expiry-address</code> and a corresponding expiry |
| queue when a message expired. Read more in the chapter about |
| <a href="undelivered-messages.html">undelivered messages</a>.</p> |
| <p><code>expiry-queue-prefix</code> defines the prefix used for automatically created expiry |
| queues. Read more in the chapter about <a href="message-expiry.html">message expiry</a>.</p> |
| <p><code>expiry-queue-suffix</code> defines the suffix used for automatically created expiry |
| queues. Read more in the chapter about <a href="message-expiry.html">message expiry</a>.</p> |
| <p><code>expiry-delay</code> defines the expiration time that will be used for messages which |
| are using the default expiration time (i.e. 0). For example, if <code>expiry-delay</code> |
| is set to "10" and a message which is using the default expiration time (i.e. |
| 0) arrives then its expiration time of "0" will be changed to "10." However, if |
| a message which is using an expiration time of "20" arrives then its expiration |
| time will remain unchanged. Setting <code>expiry-delay</code> to "-1" will disable this |
| feature. The default is "-1". Read more about <a href="message-expiry.html#configuring-expiry-addresses">message |
| expiry</a>.</p> |
| <p><code>max-delivery-attempts</code> defines how many time a cancelled message can be |
| redelivered before sending to the <code>dead-letter-address</code>. Read more about |
| <a href="undelivered-messages.html#configuring-dead-letter-addresses">undelivered |
| messages</a>.</p> |
| <p><code>redelivery-delay</code> defines how long to wait before attempting redelivery of a |
| cancelled message. Default is <code>0</code>. Read more about <a href="undelivered-messages.html#configuring-delayed-redelivery">undelivered |
| messages</a>.</p> |
| <p><code>redelivery-delay-multiplier</code> defines the number by which the |
| <code>redelivery-delay</code> will be multiplied on each subsequent redelivery attempt. |
| Default is <code>1.0</code>. Read more about <a href="undelivered-messages.html#configuring-delayed-redelivery">undelivered |
| messages</a>.</p> |
| <p><code>redelivery-collision-avoidance-factor</code> defines an additional factor used to |
| calculate an adjustment to the <code>redelivery-delay</code> (up or down). Default is |
| <code>0.0</code>. Valid values are between 0.0 and 1.0. Read more about <a href="undelivered-messages.html#configuring-delayed-redelivery">undelivered |
| messages</a>.</p> |
| <p><code>max-size-bytes</code>, <code>page-size-bytes</code>, & <code>page-max-cache-size</code> are used to |
| configure paging on an address. This is explained |
| <a href="paging.html#configuration">here</a>.</p> |
| <p><code>max-size-bytes-reject-threshold</code> is used with the address full <code>BLOCK</code> policy, |
| the maximum size (in bytes) an address can reach before messages start getting |
| rejected. Works in combination with <code>max-size-bytes</code> <strong>for AMQP clients only</strong>. |
| Default is <code>-1</code> (i.e. no limit).</p> |
| <p><code>address-full-policy</code>. This attribute can have one of the following values: |
| <code>PAGE</code>, <code>DROP</code>, <code>FAIL</code> or <code>BLOCK</code> and determines what happens when an address |
| where <code>max-size-bytes</code> is specified becomes full. The default value is <code>PAGE</code>. |
| If the value is <code>PAGE</code> then further messages will be paged to disk. If the |
| value is <code>DROP</code> then further messages will be silently dropped. If the value is |
| <code>FAIL</code> then further messages will be dropped and an exception will be thrown on |
| the client-side. If the value is <code>BLOCK</code> then client message producers will |
| block when they try and send further messages. See the <a href="flow-control.html">Flow |
| Control</a> and <a href="paging.html">Paging</a> chapters for more info.</p> |
| <p><code>message-counter-history-day-limit</code> is the number of days to keep message |
| counter history for this address assuming that <code>message-counter-enabled</code> is |
| <code>true</code>. Default is <code>0</code>.</p> |
| <p><code>last-value-queue</code> is <strong>deprecated</strong>. See <code>default-last-value-queue</code>. It |
| defines whether a queue only uses last values or not. Default is <code>false</code>. Read |
| more about <a href="last-value-queues.html">last value queues</a>.</p> |
| <p><code>default-last-value-queue</code> defines whether a queue only uses last values or |
| not. Default is <code>false</code>. This value can be overridden at the queue level using |
| the <code>last-value</code> boolean. Read more about <a href="last-value-queues.html">last value |
| queues</a>.</p> |
| <p><code>default-exclusive-queue</code> defines whether a queue will serve only a single |
| consumer. Default is <code>false</code>. This value can be overridden at the queue level |
| using the <code>exclusive</code> boolean. Read more about <a href="exclusive-queues.html">exclusive |
| queues</a>.</p> |
| <p><code>default-consumers-before-dispatch</code> defines the number of consumers needed on a |
| queue bound to the matching address before messages will be dispatched to those |
| consumers. Default is <code>0</code>. This value can be overridden at the queue level using |
| the <code>consumers-before-dispatch</code> boolean. This behavior can be tuned using |
| <code>delay-before-dispatch</code> on the queue itself or by using the |
| <code>default-delay-before-dispatch</code> address-setting.</p> |
| <p><code>default-delay-before-dispatch</code> defines the number of milliseconds the broker |
| will wait for the configured number of consumers to connect to the matching queue |
| before it will begin to dispatch messages. Default is <code>-1</code> (wait forever).</p> |
| <p><code>redistribution-delay</code> defines how long to wait when the last consumer is |
| closed on a queue before redistributing any messages. Read more about |
| <a href="clusters.html#message-redistribution">clusters</a>.</p> |
| <p><code>send-to-dla-on-no-route</code>. If a message is sent to an address, but the server |
| does not route it to any queues (e.g. there might be no queues bound to that |
| address, or none of the queues have filters that match) then normally that |
| message would be discarded. However, if this parameter is <code>true</code> then such a |
| message will instead be sent to the <code>dead-letter-address</code> (DLA) for that |
| address, if it exists.</p> |
| <p><code>slow-consumer-threshold</code>. The minimum rate of message consumption allowed |
| before a consumer is considered "slow." Measured in messages-per-second. |
| Default is <code>-1</code> (i.e. disabled); any other valid value must be greater than 0. |
| Read more about <a href="slow-consumers.html">slow consumers</a>.</p> |
| <p><code>slow-consumer-policy</code>. What should happen when a slow consumer is detected. |
| <code>KILL</code> will kill the consumer's connection (which will obviously impact any |
| other client threads using that same connection). <code>NOTIFY</code> will send a |
| CONSUMER_SLOW management notification which an application could receive and |
| take action with. Read more about <a href="slow-consumers.html">slow consumers</a>.</p> |
| <p><code>slow-consumer-check-period</code>. How often to check for slow consumers on a |
| particular queue. Measured in <em>seconds</em>. Default is <code>5</code>. Read more about <a href="slow-consumers.html">slow |
| consumers</a>.</p> |
| <p><code>auto-create-jms-queues</code> is <strong>deprecated</strong>. See <code>auto-create-queues</code>. Whether |
| or not the broker should automatically create a JMS queue when a JMS message is |
| sent to a queue whose name fits the address <code>match</code> (remember, a JMS queue is |
| just a core queue which has the same address and queue name) or a JMS consumer |
| tries to connect to a queue whose name fits the address <code>match</code>. Queues which |
| are auto-created are durable, non-temporary, and non-transient. Default is |
| <code>true</code>.</p> |
| <p><code>auto-delete-jms-queues</code> is <strong>deprecated</strong>. See <code>auto-delete-queues</code>. Whether |
| or not the broker should automatically delete auto-created JMS queues when they |
| have both 0 consumers and 0 messages. Default is <code>true</code>.</p> |
| <p><code>auto-create-jms-topics</code> is <strong>deprecated</strong>. See <code>auto-create-addresses</code>. |
| Whether or not the broker should automatically create a JMS topic when a JMS |
| message is sent to a topic whose name fits the address <code>match</code> (remember, a JMS |
| topic is just a core address which has one or more core queues mapped to it) or |
| a JMS consumer tries to subscribe to a topic whose name fits the address |
| <code>match</code>. Default is <code>true</code>.</p> |
| <p><code>auto-delete-jms-topics</code> is <strong>deprecated</strong>. See <code>auto-delete-addresses</code>. |
| Whether or not the broker should automatically delete auto-created JMS topics |
| once the last subscription on the topic has been closed. Default is <code>true</code>.</p> |
| <p><code>auto-create-queues</code>. Whether or not the broker should automatically create a |
| queue when a message is sent or a consumer tries to connect to a queue whose |
| name fits the address <code>match</code>. Queues which are auto-created are durable, |
| non-temporary, and non-transient. Default is <code>true</code>. <strong>Note:</strong> automatic queue |
| creation does <em>not</em> work for the core client. The core API is a low-level API |
| and is not meant to have such automation.</p> |
| <p><code>auto-delete-queues</code>. Whether or not the broker should automatically delete |
| auto-created queues when they have both 0 consumers and the message count is |
| less than or equal to <code>auto-delete-queues-message-count</code>. Default is |
| <code>true</code>.</p> |
| <p><code>auto-delete-created-queues</code>. Whether or not the broker should automatically delete |
| created queues when they have both 0 consumers and the message count is |
| less than or equal to <code>auto-delete-queues-message-count</code>. Default is |
| <code>false</code>.</p> |
| <p><code>auto-delete-queues-delay</code>. How long to wait (in milliseconds) before deleting |
| auto-created queues after the queue has 0 consumers and the message count is |
| less than or equal to <code>auto-delete-queues-message-count</code>. |
| Default is <code>0</code> (delete immediately). The broker's <code>address-queue-scan-period</code> controls |
| how often (in milliseconds) queues are scanned for potential deletion. Use <code>-1</code> |
| to disable scanning. The default scan value is <code>30000</code>.</p> |
| <p><code>auto-delete-queues-message-count</code>. The message count that the queue must be |
| less than or equal to before deleting auto-created queues. |
| To disable message count check <code>-1</code> can be set. |
| Default is <code>0</code> (empty queue).</p> |
| <p><strong>Note:</strong> the above auto-delete address settings can also be configured |
| individually at the queue level when a client auto creates the queue.</p> |
| <p>For Core API it is exposed in createQueue methods. </p> |
| <p>For Core JMS you can set it using the destination queue attributes |
| <code>my.destination?auto-delete=true&auto-delete-delay=120000&auto-delete-message-count=-1</code></p> |
| <p><code>config-delete-queues</code>. How the broker should handle queues deleted on config |
| reload, by delete policy: <code>OFF</code> or <code>FORCE</code>. Default is <code>OFF</code>. Read more about |
| <a href="config-reload.html">configuration reload</a>.</p> |
| <p><code>auto-create-addresses</code>. Whether or not the broker should automatically create |
| an address when a message is sent to or a consumer tries to consume from a |
| queue which is mapped to an address whose name fits the address <code>match</code>. |
| Default is <code>true</code>. <strong>Note:</strong> automatic address creation does <em>not</em> work for the |
| core client. The core API is a low-level API and is not meant to have such |
| automation.</p> |
| <p><code>auto-delete-addresses</code>. Whether or not the broker should automatically delete |
| auto-created addresses once the address no longer has any queues. Default is |
| <code>true</code>.</p> |
| <p><code>auto-delete-addresses-delay</code>. How long to wait (in milliseconds) before |
| deleting auto-created addresses after they no longer have any queues. Default |
| is <code>0</code> (delete immediately). The broker's <code>address-queue-scan-period</code> controls |
| how often (in milliseconds) addresses are scanned for potential deletion. Use |
| <code>-1</code> to disable scanning. The default scan value is <code>30000</code>.</p> |
| <p><code>config-delete-addresses</code>. How the broker should handle addresses deleted on |
| config reload, by delete policy: <code>OFF</code> or <code>FORCE</code>. Default is <code>OFF</code>. Read more |
| about <a href="config-reload.html">configuration reload</a>.</p> |
| <p><code>management-browse-page-size</code> is the number of messages a management resource |
| can browse. This is relevant for the "browse" management method exposed on the |
| queue control. Default is <code>200</code>.</p> |
| <p><code>default-purge-on-no-consumers</code> defines a queue's default |
| <code>purge-on-no-consumers</code> setting if none is provided on the queue itself. |
| Default is <code>false</code>. This value can be overridden at the queue level using the |
| <code>purge-on-no-consumers</code> boolean. Read more about <a href="#non-durable-subscription-queue">this |
| functionality</a>.</p> |
| <p><code>default-max-consumers</code> defines a queue's default <code>max-consumers</code> setting if |
| none is provided on the queue itself. Default is <code>-1</code> (i.e. no limit). This |
| value can be overridden at the queue level using the <code>max-consumers</code> boolean. |
| Read more about <a href="#shared-durable-subscription-queue-using-max-consumers">this |
| functionality</a>.</p> |
| <p><code>default-queue-routing-type</code> defines the routing-type for an auto-created queue |
| if the broker is unable to determine the routing-type based on the client |
| and/or protocol semantics. Default is <code>MULTICAST</code>. Read more about <a href="#routing-type">routing |
| types</a>.</p> |
| <p><code>default-address-routing-type</code> defines the routing-type for an auto-created |
| address if the broker is unable to determine the routing-type based on the |
| client and/or protocol semantics. Default is <code>MULTICAST</code>. Read more about |
| <a href="#routing-type">routing types</a>.</p> |
| <p><code>default-consumer-window-size</code> defines the default <code>consumerWindowSize</code> value |
| for a <code>CORE</code> protocol consumer, if not defined the default will be set to |
| 1 MiB (1024 * 1024 bytes). The consumer will use this value as the window size |
| if the value is not set on the client. Read more about |
| <a href="flow-control.html">flow control</a>.</p> |
| <p><code>default-ring-size</code> defines the default <code>ring-size</code> value for any matching queue |
| which doesn't have <code>ring-size</code> explicitly defined. If not defined the default will |
| be set to -1. Read more about <a href="ring-queues.html">ring queues</a>.</p> |
| <p><code>retroactive-message-count</code> defines the number of messages to preserve for future |
| queues created on the matching address. Defaults to 0. Read more about |
| <a href="retroactive-addresses.html">retroactive addresses</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="upgrading.html" class="navigation navigation-prev " aria-label="Previous page: Upgrading"> |
| <i class="fa fa-angle-left"></i> |
| </a> |
| |
| |
| <a href="protocols-interoperability.html" class="navigation navigation-next " aria-label="Next page: Protocols and Interoperability"> |
| <i class="fa fa-angle-right"></i> |
| </a> |
| |
| |
| |
| </div> |
| |
| <script> |
| var gitbook = gitbook || []; |
| gitbook.push(function() { |
| gitbook.page.hasChanged({"page":{"title":"Address Model","level":"1.10","depth":1,"next":{"title":"Protocols and Interoperability","level":"1.11","depth":1,"path":"protocols-interoperability.md","ref":"protocols-interoperability.md","articles":[]},"previous":{"title":"Upgrading","level":"1.9","depth":1,"path":"upgrading.md","ref":"upgrading.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/artemis","issues":"https://issues.apache.org/jira/browse/ARTEMIS","contribute":"http://activemq.apache.org/contributing.html"},"gitbook":"3.x.x","description":"ActiveMQ Artemis User Guide and Reference Documentation"},"file":{"path":"address-model.md","mtime":"2020-04-27T19:30:24.000Z","type":"markdown"},"gitbook":{"version":"3.1.1","time":"2020-04-29T20:47:49.444Z"},"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> |
| |
