Turning off producer flow control just means the broker won’t pause fast producers to allow for consumers to catch up— it is a ’self-healing’ type feature. With it off, producers will simply get errors when resources are exhausted.
The feature helps prevent producer-side errors in the scenario where a few micro pauses would allow things to settle down without any errors being thrown at all. -Matt Pavlovich > On Jan 6, 2022, at 12:36 PM, Daniel Navrotsky <[email protected]> > wrote: > > Thank you Matt for the answer. > > I am trying to understand the difference between producerFlowControl=true or > false. I understand that the type of the cursor defines the resources. When > resources are exhausted the flow control will take place no matter if > producerFlowControl=true or false. Can you please bring an example of cursor > and message type where the behavior will be different depending on > producerFlowControl param? > > Thanks, > > Best regards, > Daniel > > -----Original Message----- > From: Matt Pavlovich <[email protected]> > Sent: Thursday, January 6, 2022 7:42 PM > To: [email protected] > Subject: Re: Mismatch in documentation regarding producerFlowControl behavior > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > Daniel- > > The documentation looks correct. The “triggers” for producer flow control > vary based on the configurations and message type (persistent or > non-persistent). What is different in the various configuration noted below > are what what constitutes “resources” for non-persistent messages. > > For non-persistent messages: > > a. Default cursor will flow control when memoryLimit and/or tempUsageLimit > reached > -or- > b. vmQueueCurosr will flow control on memoryLimit only (since temp and store > usage are not used) > > Hope this helps. > > -Matt Pavlovich > >> On Jan 5, 2022, at 4:58 PM, Daniel Navrotsky <[email protected]> >> wrote: >> >> Hello, >> >> It looks like there is a mismatch in the documentation. From piece 1 (below) >> I understand that messages would be shunted into the temporary file even if >> producerFlowControl=true, but from piece 2 it sounds like it only would >> happen if producerFlowControl=false >> >> >> Piece 1 >> https://activemq.apache.org/producer-flow-control.html >> 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 <vmQueueCursor> >> >> Piece 2 >> https://activemq.apache.org/per-destination-policies >> producerFlowControl - If true the broker will throttle (flow-control) the >> producer. Throttling is achieved either by withholding the producer’s ACK or >> by raising a javax.jms.ResourceAllocationException (that’s propagated back >> to the client) when local resources, e.g., memory and/or storage, have been >> exhausted. If false excess messages will be written to the message store to >> prevent memory exhaustion. However, when the message store reaches capacity >> the producer will be throttled until resources are freed. >> >> >> Best regards, >> Daniel >
