<div class="wiki-content maincontent"><h2>Producer Flow Control</h2><p>In ActiveMQ 4.x flow control was implemented using TCP flow control. The underlying network connection of throttled consumers was suspended to enforce flow control limits. This strategy is very efficient but can lead to deadlocks if there are multiple producers and consumers sharing the same connection.</p><p>As of ActiveMQ 5.0, we can now individually flow control each producer on a shared connection without having to suspend the entire connection. By 'flow control' we mean that if the broker detects that the memory limit for the destination, or the temp- or file-store limits for the broker, have been exceeded, then the flow of messages can be slowed down. The producer will be either blocked until resources are available <em>or</em> will receive a JMSException: this behaviour is configurable and described in the section below on <code>&lt;systemUsage&gt;</code>.</p><p>It's worth noting that the default <code>&lt;systemUsage&gt;</code> settings will cause the producer to <em>block</em> when the <code>memoryLimit</code> or <code>&lt;systemUsage&gt;</code> limits are reached: this blocking behaviour is sometimes misinterpreted as a 'hung producer', when in fact the producer is simply diligently waiting until space is available.</p><ul><li>Messages that are sent synchronously will automatically use per producer flow control; this applies generally to persistent messages which are sent synchronously <em>unless</em> you enable the <code>useAsyncSend</code> flag.</li></ul><ul><li>Producers that use <link><page ri:content-title="Async Sends"></page></link> - generally speaking, producers of non-persistent messages - don't bother waiting for any acknowledgement from the broker; so, if a memory limit has been exceeded, you will <em>not</em> get notfied. If you do want to be aware of broker limits being exceeded, you will need to configure the ProducerWindowSize connection option so that even async messages are flow controlled per producer.</li></ul><structured-macro ac:macro-id="81758a12-e709-4add-8394-366b2ed46dae" ac:name="code" ac:schema-version="1"><plain-text-body>ActiveMQConnectionFactory connctionFactory = ...
connctionFactory.setProducerWindowSize(1024000);
</plain-text-body></structured-macro><p>The ProducerWindowSize is the maximum number of bytes of data that a producer will transmit to a broker before waiting for acknowledgment messages from the broker that it has accepted the previously sent messages.</p><p>Alternatively, if you're sending non-persisted messages (which are by default sent async), and want to be informed if the queue or topic's memory limit has been breached, then you can simply configure the connection factory to 'alwaysSyncSend'. While this is going to be slower, it will ensure that your message producer is informed immediately of memory issues.</p><p>If you like, you can disable flow control for specific JMS queues and topics on the broker by setting the <code>producerFlowControl</code> flag to false on the appropriate destination policy in the Broker configuration - e.g.</p><structured-macro ac:macro-id="25a71a92-ce5b-48c5-b53f-b867a8efc000" ac:name="code" ac:schema-version="1"><parameter ac:name="">xml</parameter><plain-text-body>&lt;destinationPolicy&gt;
  &lt;policyMap&gt;
    &lt;policyEntries&gt;
      &lt;policyEntry topic="FOO.&gt;" producerFlowControl="false"/&gt;
    &lt;/policyEntries&gt;
  &lt;/policyMap&gt;
&lt;/destinationPolicy&gt;
</plain-text-body></structured-macro><p>see <link><page ri:content-title="Xml Configuration"></page><plain-text-link-body>Broker Configuration</plain-text-link-body></link>.</p><p>Note that, since the introduction of the new file cursor in ActiveMQ 5.x, non-persisted messages are shunted into the temporary file store to reduce the amount of memory used for non-persistent messaging. As a result, you may find that a queue's memoryLimit is never reached, as the cursor doesn't use very much memory. If you really do want to keep all your non-persistent messages in memory, and stop producers when the limit is reached, you should configure the <code>&lt;vmQueueCursor&gt;</code>.</p><structured-macro ac:macro-id="e0611bd3-5d45-4ea5-a794-2e753cc20011" ac:name="code" ac:schema-version="1"><parameter ac:name="">xml</parameter><plain-text-body>&lt;policyEntry queue="&gt;" producerFlowControl="true" memoryLimit="1mb"&gt;    
  &lt;pendingQueuePolicy&gt;
    &lt;vmQueueCursor/&gt;
  &lt;/pendingQueuePolicy&gt;
&lt;/policyEntry&gt;
</plain-text-body></structured-macro><p>The fragment above will ensure that all non-persistent queue messages are kept in memory, with each queue having a limit of 1Mb.</p><h3>How Producer Flow Control works</h3><p>If you are sending a persistent message (so that a response of the <link><page ri:content-title="OpenWire"></page></link> Message is expected then the broker will send the producer a <a shape="rect" href="http://activemq.apache.org/maven/5.9.0/apidocs/index.html">ProducerAck</a> message. This informs the producer that the previous sending window has been processed, so that it can now send another window. Its kinda like consumer acks but in reverse.</p><h4>Advantage</h4><p>So a nice producer might wait for a producer ack before sending more data, to avoid flooding the broker (and forcing the broker to block the entire connection if a slow consumer occurs). To see how this works in source code, check out the <a shape="rect" href="http://activemq.apache.org/maven/5.9.0/apidocs/index.html">ActiveMQMessageProducer</a> code.</p><p>Though a client can ignore the producer ACKs altogether and the broker should just stall the transport if it has to for slow consumer handling; though this does mean it'll stall the entire connection.</p><h3>Configure Client-Side Exceptions</h3><p>An alternative to the indefinite blocking of the <code>send()</code> operation when no space is free on the broker is to instead configure that an exception to be thrown on the client-side. By configuring the <code>sendFailIfNoSpace</code> property to <code>true</code>, the broker will cause the <code>send()</code> operation to fail with a <code>javax.jms.ResourceAllocationException</code>, which will propagate to the client. Below is an example of this configuration:</p><structured-macro ac:macro-id="b109dd0a-ab99-4851-9352-a12dc64d7ef7" ac:name="code" ac:schema-version="1"><plain-text-body>&lt;systemUsage&gt;
 &lt;systemUsage sendFailIfNoSpace="true"&gt;
   &lt;memoryUsage&gt;
     &lt;memoryUsage limit="20 mb"/&gt;
   &lt;/memoryUsage&gt;
 &lt;/systemUsage&gt;
&lt;/systemUsage&gt;</plain-text-body></structured-macro><p>The advantage of this property is that the client can catch the <code>javax.jms.ResourceAllocationException</code>, wait a bit and retry the <code>send()</code> operation instead of just hanging indefinitely.</p><p>Starting in version 5.3.1 the <code>sendFailIfNoSpaceAfterTimeout</code> property has been added. This property causes the <code>send()</code> operation to fail with an exception on the client-side, but only after waiting the given amount of time. If space on the broker is still not freed after the configured amount of time, only then does the <code>send()</code> operation fail with an exception to the client-side. Below is an example:</p><structured-macro ac:macro-id="3633fe45-9e7f-445f-bc4d-0b644c1563d1" ac:name="code" ac:schema-version="1"><plain-text-body>&lt;systemUsage&gt;
 &lt;systemUsage sendFailIfNoSpaceAfterTimeout="3000"&gt;
   &lt;memoryUsage&gt;
     &lt;memoryUsage limit="20 mb"/&gt;
   &lt;/memoryUsage&gt;
 &lt;/systemUsage&gt;
&lt;/systemUsage&gt;</plain-text-body></structured-macro><p>The timeout is defined in milliseconds so the example above waits for three seconds before failing the <code>send()</code> operation with an exception to the client-side. The advantage of this property is that it will block for the configured amount of time instead of failing immediately or blocking indefinitely. This property offers not only an improvement on the broker-side, but also an improvement for the client so it can catch the exception, wait a bit and retry the <code>send()</code> operation.</p><p>Starting in version 5.16.0 the <code>sendFailIfNoSpace</code> and <span><code>sendFailIfNoSpaceAfterTimeout</code> can be configured on a per destination basis via <link><page ri:content-title="Per Destination Policies"></page><plain-text-link-body>destination policies</plain-text-link-body></link>.</span></p><h2>Disabling Flow Control</h2><p>A common requirement is to disable flow control so that message dispatching continues until all available disk is used up by pending messages (whether persistent or non persistent messaging is configured). To do this enable <link><page ri:content-title="Message Cursors"></page></link>.</p><h2>System usage</h2><p>You can also slow down producers via some attributes on the <code>&lt;systemUsage&gt;</code> element. Take a look at the following example:</p><structured-macro ac:macro-id="69f65235-7613-462c-81a2-7b9cb20474c0" ac:name="code" ac:schema-version="1"><plain-text-body>&lt;systemUsage&gt;
  &lt;systemUsage&gt;
    &lt;memoryUsage&gt;
      &lt;memoryUsage limit="64 mb" /&gt;
    &lt;/memoryUsage&gt;
    &lt;storeUsage&gt;
      &lt;storeUsage limit="100 gb" /&gt;
    &lt;/storeUsage&gt;
    &lt;tempUsage&gt;
      &lt;tempUsage limit="10 gb" /&gt;
    &lt;/tempUsage&gt;
  &lt;/systemUsage&gt;
&lt;/systemUsage&gt;</plain-text-body></structured-macro><p>You can set limits of memory for <code>NON_PERSISTENT</code> messages, disk storage for <code>PERSITENT</code> messages and total usage for temporary messages, the broker will use before it slowdown producers. <em>Using the default settings shown above, the broker will block the <code>send()</code> call until some messages are consumed and space becomes available on the broker.</em> The default values are shown above, you will probably need to increase these values for your environment.</p><p><span style="color: rgb(102,0,51);">PercentUsage</span></p><p>&#160;Both StoreUsage and TempUsage support a percentLimit attribute where the limit is determined as a percentage of the total available. From version 5.15.x there is an additional related total attribute that can be used to explicitly set the total available such that the file system is not queried. This is useful in the case that only part of a disk partition is available to the broker or where the underlying file store reports &gt; Long.MAX_VALUE available capacity (e.g: EFS) which will overflow the long return value of&#160;<a shape="rect" href="http://java.io">java.io</a>.File#getTotalSpace. Note that when a total is specified, that actual data available will not be validated agains the file system, just the store usage relative to that absolute total.</p></div>