Author: buildbot
Date: Thu Sep 25 14:20:52 2014
New Revision: 923536
Log:
Production update by buildbot for activemq
Modified:
websites/production/activemq/content/cache/main.pageCache
websites/production/activemq/content/mqtt.html
websites/production/activemq/content/subscription-recovery-policy.html
Modified: websites/production/activemq/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/activemq/content/mqtt.html
==============================================================================
--- websites/production/activemq/content/mqtt.html (original)
+++ websites/production/activemq/content/mqtt.html Thu Sep 25 14:20:52 2014
@@ -35,6 +35,7 @@
<link
href='http://activemq.apache.org/styles/highlighter/styles/shCore.css'
rel='stylesheet' type='text/css' />
<link
href='http://activemq.apache.org/styles/highlighter/styles/shThemeEclipse.css'
rel='stylesheet' type='text/css' />
<script
src='http://activemq.apache.org/styles/highlighter/scripts/shCore.js'
type='text/javascript'></script>
+ <script
src='http://activemq.apache.org/styles/highlighter/scripts/shBrushJava.js'
type='text/javascript'></script>
<script
src='http://activemq.apache.org/styles/highlighter/scripts/shBrushXml.js'
type='text/javascript'></script>
<script type="text/javascript">
@@ -93,9 +94,12 @@
<script class="theme: Default; brush: xml; gutter: false"
type="syntaxhighlighter"><![CDATA[ <transportConnector
name="mqtt+nio" uri="mqtt+nio+ssl://localhost:1883"/>
]]></script>
</div></div><ul><li>For more details on using SSL with ActiveMQ see the
following article (<a shape="rect" class="external-link"
href="http://activemq.apache.org/how-do-i-use-ssl.html";>How do I use
SSL</a>).</li></ul><h3 id="MQTT-WorkingwithDestinationswithMQTT">Working with
Destinations with MQTT</h3><p>MQTT supports hierarchies and wildcards, though
the delimiters and characters are different: - Here's the mapping:</p><div
class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1"
rowspan="1" class="confluenceTh"><p>function</p></th><th colspan="1"
rowspan="1" class="confluenceTh"><p>ActiveMQ</p></th><th colspan="1"
rowspan="1" class="confluenceTh"><p>MQTT</p></th></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>separator</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p><code>.</code></p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p><code>/</code></p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>element</p></t
d><td colspan="1" rowspan="1"
class="confluenceTd"><p><code>*</code></p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p><code>+<br clear="none"></code></p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>sub tree</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p><code>></code></p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p><code>#<br
clear="none"></code></p></td></tr></tbody></table></div><p>These values are
automatically transposed between clients using JMS/NMS/Stomp and clients using
MQTTT. For example - a client subscribing to "foo/#/bar" would receive messages
published on a JMS Topic of foo.blah.bar.</p><h3
id="MQTT-Messagetransformations">Message transformations</h3><p>MQTT messages
are transformed into an JMS ByteMessage. Conversely, the body of any JMS
Message is converted to a byte buffer to be the payload of an MQTT
message.</p><h3 id="MQTT-KeepAlive">Keep Alive</h3><p>When a client connects,
it will send a keep-alive dur
ation, usually defaulting to 10s. ActiveMQ will honor the keep-alive duration
by setting up an Inactivity Monitor that allows a grace period of 1.5 *
duration. After that grace period duration elapses a connection could be closed
if there is no activity. A broker receiving a PINGREQ and sending PINGRESP is
considered activity to keep the connection opened.</p><p>If a client sends a
keep-alive value of 0, ActiveMQ will not set up an <a shape="rect"
class="external-link"
href="http://activemq.apache.org/activemq-inactivitymonitor.html";>Inactivity
Monitor</a> and connections will not be auto-shutdown due to inactivity. This
however can lead to potentially leaky connections, so a default keep alive can
be set on the server side (by an admin, for example) to not allow inactive
connections to hang. This default keep alive would only be used if specified
and if the client requests a keep-alive value of 0. The unit for the keep-alive
value is milliseconds.</p><p>To enable a default, server-
side MQTT keep alive:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<script class="theme: Default; brush: xml; gutter: false"
type="syntaxhighlighter"><![CDATA[<transportConnector name="mqtt"
uri="mqtt://localhost:1883?transport.defaultKeepAlive=60000"/>
-]]></script>
-</div></div></div>
+<script class="theme: Default; brush: xml; gutter: false"
type="syntaxhighlighter"><![CDATA[<transportConnector name="mqtt"
uri="mqtt://localhost:1883?transport.defaultKeepAlive=60000"/>]]></script>
+</div></div><h3 id="MQTT-MessagePrefetch">Message Prefetch</h3><p>When MQTT
client connects, it locally create JMS-like consumer to the broker. By default
this consumer is created with prefetch size of 1 (message prefetching is
explained <a shape="rect" href="what-is-the-prefetch-limit-for.html">here</a>
in more details). Usually, increasing message prefetch size can boost the
performance as messages are dispatched to consumers in batches instead of
waiting for the individual acknowledges. To increase prefetch size, you can
use <em>activeMQSubscriptionPrefetch</em> transport option, like</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[<transportConnector name="mqtt"
uri="mqtt://localhost:1883?transport.activeMQSubscriptionPrefetch=32766"/>]]></script>
+</div></div><h3 id="MQTT-SubscriptionStrategy">Subscription
Strategy</h3><p>ActiveMQ is a JMS broker in its core, so there needs to be some
mapping between MQTT subscriptions and JMS semantics. Subscriptions with QoS=0
(At Most Once) are directly mapped to plain JMS non-persistent topics. For
reliable messaging, QoS=1 and QoS=2, by default subscriptions are transformed
to JMS durable topic subscribers. This behaviour is desired in most scenarios.
For some use cases, it is useful to map these subscriptions to <a shape="rect"
href="virtual-destinations.html">virtual topics</a>. Virtual topics provide a
better scalability and are generally better solution if you want to use you
MQTT subscribers over network of brokers. To change subscription strategy to
use virtual topic, use the following settings:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[<transportConnector name="mqtt"
uri="mqtt://localhost:1883?transport.subscriptionStrategy=mqtt-virtual-topic-subscriptions"/>]]></script>
+</div></div><h3 id="MQTT-RetainedMessages">Retained Messages</h3><p>If a
message has been published with the <em>retain</em> flag set, then the message
will be 'remembered' by the topic so that if a new subscription arrives, the
last retained message is sent to the subscription. Underneath, the broker uses
<a shape="rect" href="subscription-recovery-policy.html">retained message
subscription recovery policy</a> to retain messages
with <em>ActiveMQ.Retain</em> property set. During the message conversion,
MQTT messages with retain flag become JMS message with the
<em>ActiveMQ.Retain </em>property set and retained by the broker.</p></div>
</td>
<td valign="top">
<div class="navigation">
Modified: websites/production/activemq/content/subscription-recovery-policy.html
==============================================================================
--- websites/production/activemq/content/subscription-recovery-policy.html
(original)
+++ websites/production/activemq/content/subscription-recovery-policy.html Thu
Sep 25 14:20:52 2014
@@ -72,29 +72,7 @@
<tbody>
<tr>
<td valign="top" width="100%">
-<div class="wiki-content maincontent"><p>The subscription recovery policy
allows you to go back in time when you subscribe to a topic.</p>
-
-<p>For example imagine you are processing a price feed; you're using a
federated network and either a network glitch occurs or someone kills the
broker you're talking to. If you reconnect to another broker in the cluster you
may have lost messages.</p>
-
-<p>So we support a timed or fixed size recovery buffer so that if you
reconnect to another broker within some time period (depending on volume &
RAM this could be 30 seconds to 5 minutes), then any messages you missed during
the downtime are redelivered before new messages are delivered to you.</p>
-
-<p>For more information see <a shape="rect"
href="retroactive-consumer.html">Retroactive Consumer</a></p>
-
-<h3 id="SubscriptionRecoveryPolicy-Lastimagecaching">Last image caching</h3>
-
-<p>Its often common in financial market data type worlds to want to know the
latest price of say IBM stock along with get all the future updates to the
price. Historically you often had a request-reply snapshot quote service for
the latest price, then you subscribe to a topic for updates. The issue is the
client then has 2 APIs / middlewares to deal with - often quite different
things - plus you have an ordering issue (race condition) - the update could
beat the last price request so you can get out of order (going back in time to
an old price, which could be very old).</p>
-
-<p>One of our <em>subscription recovery policy</em> implementations is called
<strong>Last Image Subscription Policy</strong> which will ensure that when you
subscribe to a topic (say PRICES.NASDAQ.IBM), you will receive the last image
(the last message that was sent on that topic) plus any updates which occur in
the future, with ordering to ensure that the last image is always first before
any new messages arrive.</p>
-
-<p>A common problem in market data type situations is that you may have a
cache of last image prices, then a feed of new price changes; if you request
the last price from the cache and subscribe to new prices; depending on how you
do it you can either, miss an update or receive a newer update before the old
last image arrives (so either get out of order messages).</p>
-
-
-<p>Note that you can configure the subscription recovery policy, and most
other policies on different destinations or wildcards. So you may use last
image policy for prices on topics only and use a buffered fixed size policy for
other notifications on different topics etc.</p>
-
-<h3 id="SubscriptionRecoveryPolicy-SummaryofAvailableRecoveryPolicies">Summary
of Available Recovery Policies</h3>
-<div class="table-wrap"><table class="confluenceTable"><tbody><tr><th
colspan="1" rowspan="1" class="confluenceTh"><p> Policy Name </p></th><th
colspan="1" rowspan="1" class="confluenceTh"><p> Sample Configuration
</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p> Description
</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>
FixedSizedSubscriptionRecoveryPolicy </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> <fixedSizedSubscriptionRecoveryPolicy
maximumSize="1024"/> </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> Keep a fixed amount of memory in RAM for message
history which is evicted in time order. </p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p> FixedCountSubscriptionRecoveryPolicy
</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>
<fixedCountSubscriptionRecoveryPolicy maximumSize="100"/> </p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p> Keep a fixed count of last
messages. </p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p> LastImageSubscriptionRecoveryPolicy </p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>
<lastImageSubscriptionRecoveryPolicy/> </p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p> Keep only the last message.
</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>
NoSubscriptionRecoveryPolicy </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> <noSubscriptionRecoveryPolicy/> </p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p> Disables message recovery.
</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>
QueryBasedSubscriptionRecoveryPolicy </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> <queryBasedSubscriptionRecoveryPolicy
query="JMSType = 'car' AND color = 'blue'"/> </p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p> Perform a user specific query mechanism to
load any message they may have
missed. Details on message selectors are available here: </p>
-<a shape="rect" class="external-link"
href="http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Message.html";
rel="nofollow">http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Message.html</a>
-<p></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>
TimedSubscriptionRecoveryPolicy </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> <timedSubscriptionRecoveryPolicy
recoverDuration="60000" /> </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> Keep a timed buffer of messages around in memory and
use that to recover new subscriptions. Recovery time is in milliseconds.
</p></td></tr></tbody></table></div></div>
+<div class="wiki-content maincontent"><p>The subscription recovery policy
allows you to go back in time when you subscribe to a topic.</p><p>For example
imagine you are processing a price feed; you're using a federated network and
either a network glitch occurs or someone kills the broker you're talking to.
If you reconnect to another broker in the cluster you may have lost
messages.</p><p>So we support a timed or fixed size recovery buffer so that if
you reconnect to another broker within some time period (depending on volume
& RAM this could be 30 seconds to 5 minutes), then any messages you missed
during the downtime are redelivered before new messages are delivered to
you.</p><p>For more information see <a shape="rect"
href="retroactive-consumer.html">Retroactive Consumer</a></p><h3
id="SubscriptionRecoveryPolicy-Lastimagecaching">Last image caching</h3><p>Its
often common in financial market data type worlds to want to know the latest
price of say IBM stock along with get a
ll the future updates to the price. Historically you often had a request-reply
snapshot quote service for the latest price, then you subscribe to a topic for
updates. The issue is the client then has 2 APIs / middlewares to deal with -
often quite different things - plus you have an ordering issue (race condition)
- the update could beat the last price request so you can get out of order
(going back in time to an old price, which could be very old).</p><p>One of our
<em>subscription recovery policy</em> implementations is called <strong>Last
Image Subscription Policy</strong> which will ensure that when you subscribe to
a topic (say PRICES.NASDAQ.IBM), you will receive the last image (the last
message that was sent on that topic) plus any updates which occur in the
future, with ordering to ensure that the last image is always first before any
new messages arrive.</p><p>A common problem in market data type situations is
that you may have a cache of last image prices, then a feed of n
ew price changes; if you request the last price from the cache and subscribe
to new prices; depending on how you do it you can either, miss an update or
receive a newer update before the old last image arrives (so either get out of
order messages).</p><p>Note that you can configure the subscription recovery
policy, and most other policies on different destinations or wildcards. So you
may use last image policy for prices on topics only and use a buffered fixed
size policy for other notifications on different topics etc.</p><h3
id="SubscriptionRecoveryPolicy-SummaryofAvailableRecoveryPolicies">Summary of
Available Recovery Policies</h3><div class="table-wrap"><table
class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1"
class="confluenceTh"><p>Policy Name</p></th><th colspan="1" rowspan="1"
class="confluenceTh"><p>Sample Configuration</p></th><th colspan="1"
rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>Fi
xedSizedSubscriptionRecoveryPolicy</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p><fixedSizedSubscriptionRecoveryPolicy
maximumSize="1024"/></p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Keep a fixed amount of memory in RAM for message
history which is evicted in time order.</p></td></tr><tr><td colspan="1"
rowspan="1"
class="confluenceTd"><p>FixedCountSubscriptionRecoveryPolicy</p></td><td
colspan="1" rowspan="1"
class="confluenceTd"><p><fixedCountSubscriptionRecoveryPolicy
maximumSize="100"/></p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Keep a fixed count of last
messages.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>LastImageSubscriptionRecoveryPolicy</p></td><td
colspan="1" rowspan="1"
class="confluenceTd"><p><lastImageSubscriptionRecoveryPolicy/></p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>Keep only the last
message.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceT
d"><p>NoSubscriptionRecoveryPolicy</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p><noSubscriptionRecoveryPolicy/></p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>Disables message
recovery.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>QueryBasedSubscriptionRecoveryPolicy</p></td><td
colspan="1" rowspan="1"
class="confluenceTd"><p><queryBasedSubscriptionRecoveryPolicy query="JMSType
= 'car' AND color = 'blue'"/></p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Perform a user specific query mechanism to load any
message they may have missed. Details on message selectors are available
here:</p><a shape="rect" class="external-link"
href="http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Message.html";
rel="nofollow">http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Message.html</a><p> </p></td></tr><tr><td
colspan="1" rowspan="1"
class="confluenceTd"><p>TimedSubscriptionRecoveryPolicy</p></td><td colspan="1"
rowspan=
"1" class="confluenceTd"><p><timedSubscriptionRecoveryPolicy
recoverDuration="60000" /></p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Keep a timed buffer of messages around in memory and
use that to recover new subscriptions. Recovery time is in
milliseconds.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd">RetainedMessageSubscriptionRecoveryPolicy</td><td
colspan="1" rowspan="1"
class="confluenceTd"><r<span>etainedMessageSubscriptionRecoveryPolicy/></span></td><td
colspan="1" rowspan="1" class="confluenceTd">Keep the last message with
ActiveMQ.Retain property set to true</td></tr></tbody></table></div></div>
</td>
<td valign="top">
<div class="navigation">
