activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r923536 - in /websites/production/activemq/content: cache/main.pageCache mqtt.html subscription-recovery-policy.html
Date Thu, 25 Sep 2014 14:20:52 GMT
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[
    &lt;transportConnector name=&quot;mqtt+nio&quot; uri=&quot;mqtt+nio+ssl://localhost:1883&quot;/&gt;
 ]]></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>&gt;</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[&lt;transportConnector
name=&quot;mqtt&quot; uri=&quot;mqtt://localhost:1883?transport.defaultKeepAlive=60000&quot;/&gt;
-]]></script>
-</div></div></div>
+<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[&lt;transportConnector
name=&quot;mqtt&quot; uri=&quot;mqtt://localhost:1883?transport.defaultKeepAlive=60000&quot;/&gt;]]></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&#160;<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[&lt;transportConnector
name=&quot;mqtt&quot; uri=&quot;mqtt://localhost:1883?transport.activeMQSubscriptionPrefetch=32766&quot;/&gt;]]></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[&lt;transportConnector
name=&quot;mqtt&quot; uri=&quot;mqtt://localhost:1883?transport.subscriptionStrategy=mqtt-virtual-topic-subscriptions&quot;/&gt;]]></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&#160;<em>ActiveMQ.Retain</em>
property set. During the message conversion, MQTT messages with retain flag become JMS message
with the <em>ActiveMQ.Retain&#160;</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 &amp; 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> &lt;fixedSizedSubscriptionRecoveryPolicy
maximumSize="1024"/&gt; </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> &lt;fixedCountSubscriptionRecoveryPolicy
maximumSize="100"/&gt; </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>
&lt;lastImageSubscriptionRecoveryPolicy/&gt; </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> &lt;noSubscriptionRecoveryPolicy/&gt;
</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> &lt;queryBasedSubscriptionRecoveryPolicy
query="JMSType = 'car' AND color = 'blue'"/&gt; </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>
&lt;timedSubscriptionRecoveryPolicy recoverDuration="60000" /&gt; </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 &amp; 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>&lt;fixedSizedSubscriptionRecoveryPolicy
maximumSize="1024"/&gt;</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>&lt;fixedCountSubscriptionRecoveryPolicy
maximumSize="100"/&gt;</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>&lt;lastImageSubscriptionRecoveryPolicy/&gt;</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>&lt;noSubscriptionRecoveryPolicy/&gt;</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>&lt;queryBasedSubscriptionRecoveryPolicy
query="JMSType = 'car' AND color = 'blue'"/&gt;</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>&#160;</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>TimedSubscriptionRecoveryPolicy</p></td><td
colspan="1" rowspan=
 "1" class="confluenceTd"><p>&lt;timedSubscriptionRecoveryPolicy recoverDuration="60000"
/&gt;</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">&lt;r<span>etainedMessageSubscriptionRecoveryPolicy/&gt;</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">



Mime
View raw message