activemq-artemis git commit: ARTEMIS-1316 Add docs for AMQP scheduling of messages

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

activemq-artemis git commit: ARTEMIS-1316 Add docs for AMQP scheduling of messages

tabish
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 <[hidden email]>
Authored: Thu Aug 10 14:22:52 2017 -0400
Committer: Timothy Bish <[hidden email]>
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

Loading...