You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@activemq.apache.org by ta...@apache.org on 2017/08/10 18:23:21 UTC
activemq-artemis git commit: ARTEMIS-1316 Add docs for AMQP
scheduling of messages
Repository: activemq-artemis
Updated Branches:
refs/heads/master e81c8c26d -> 2c30be880
ARTEMIS-1316 Add docs for AMQP scheduling of messages
Add some documentation for the scheduled message options with AMQP
Messages.
Project: http://git-wip-us.apache.org/repos/asf/activemq-artemis/repo
Commit: http://git-wip-us.apache.org/repos/asf/activemq-artemis/commit/2c30be88
Tree: http://git-wip-us.apache.org/repos/asf/activemq-artemis/tree/2c30be88
Diff: http://git-wip-us.apache.org/repos/asf/activemq-artemis/diff/2c30be88
Branch: refs/heads/master
Commit: 2c30be8809799d55b346a80e0d8f7e50c64d03ce
Parents: e81c8c2
Author: Timothy Bish <ta...@gmail.com>
Authored: Thu Aug 10 14:22:52 2017 -0400
Committer: Timothy Bish <ta...@gmail.com>
Committed: Thu Aug 10 14:22:52 2017 -0400
----------------------------------------------------------------------
.../en/protocols-interoperability.md | 50 +++++++++++++-------
1 file changed, 34 insertions(+), 16 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/activemq-artemis/blob/2c30be88/docs/user-manual/en/protocols-interoperability.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/protocols-interoperability.md b/docs/user-manual/en/protocols-interoperability.md
index acab4f5..92988ab 100644
--- a/docs/user-manual/en/protocols-interoperability.md
+++ b/docs/user-manual/en/protocols-interoperability.md
@@ -87,15 +87,15 @@ does not exist then an exception will be sent
> but for now you will have to add them via the configuration
### AMQP and Multicast Queues (Topics)
-
-Although amqp has no notion of topics it is still possible to treat amqp consumers or receivers as subscriptions rather
+
+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 that has only multicast enabled
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 `my-container-id:my-link-name`. if the Terminus Durability is configured
+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 `my-container-id:my-link-name`. if the Terminus Durability is configured
as NONE then a volatile multicast queue will be created.
-Artemis also supports the qpid-jms client and will respect its use of topics regardless of the prefix used for the address.
+Artemis also supports the qpid-jms client and will respect its use of topics regardless of the prefix used for the address.
### AMQP and Coordinations - Handling Transactions
@@ -110,6 +110,24 @@ or committed via the coordinator.
> `amqp:multi-txns-per-ssn`, however in this version Apache ActiveMQ Artemis will only
> support single transactions per session
+### AMQP scheduling message delivery
+
+An AMQP message can provide scheduling information that controls the time in the future when the
+message will be delivered at the earliest. This information is provided by adding a message annotation
+to the sent message.
+
+There are two different message annotations that can be used to schedule a message for later delivery:
+
+* `x-opt-delivery-time`
+The specified value must be a positive long corresponding to the time the message should be made available
+for delivery (in milliseconds).
+
+* `x-opt-delivery-delay`
+The specified value must be a positive long corresponding to the amount of milliseconds after the broker
+receives the given message before it should be made available for delivery.
+
+if both annotations are present in the same message then the broker will prefer the more specific `x-opt-delivery-time` value.
+
## OpenWire
Apache ActiveMQ Artemis now supports the
@@ -141,21 +159,21 @@ It specifies the time (milliseconds) after which the connection is closed by the
Default value is 30000.
* maxInactivityDurationInitalDelay:
-It specifies the maximum delay (milliseconds) before inactivity monitoring is started on the connection.
+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.
* 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
+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.
* 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
+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.
-Note at the beginning the InactivityMonitor negotiates the appropriate maxInactivityDuration and
+Note at the beginning the InactivityMonitor negotiates the appropriate maxInactivityDuration and
maxInactivityDurationInitalDelay. The shortest duration is taken for the connection.
More details please see [ActiveMQ InactivityMonitor](http://activemq.apache.org/activemq-inactivitymonitor.html).
@@ -338,10 +356,10 @@ 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
[connection-ttl](#connection-ttl) for more information. This value can
-be overridden using the `connection-ttl-override` property or if you
+be overridden using the `connection-ttl-override` property or if you
need a specific connectionTtl for your stomp connections without
-affecting the broker-wide `connection-ttl-override` setting, you can
-configure your stomp acceptor with the "connectionTtl" property, which
+affecting the broker-wide `connection-ttl-override` 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:
@@ -358,7 +376,7 @@ 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 `heart-beat` header or disable client-to-server
-heart-beating (e.g. by sending `0,X` in the `heart-beat` header) will have
+heart-beating (e.g. by sending `0,X` in the `heart-beat` header) will have
a connection TTL imposed upon them by the broker.
For Stomp 1.1 and 1.2 clients which send a non-zero client-to-server `heart-beat`
@@ -404,7 +422,7 @@ The minimum server-to-client heart-beat value is 500ms.
Stomp subscribers can specify an expression used to select or filter
what the subscriber receives using the `selector` header. The filter
-expression syntax follows the *core filter syntax* described in the
+expression syntax follows the *core filter syntax* described in the
[Filter Expressions](filter-expressions.md) documentation.
### Stomp and JMS interoperability