Interesting, ok that last part of the statement may be outdated. I honestly haven’t tested with producerFlowControl off in a while to know off the top of my head.
I’d be a straight-forward test.. set storeUsageLimit to something small.. turn off flow control and publish messages to see what happens next. -Matt Pavlovich > On Jan 6, 2022, at 4:32 PM, Daniel Navrotsky <[email protected]> > wrote: > > Thanks Matt, > > > > You wrote "With it off, producers will simply get errors when resources are > exhausted". > > But in the description to producerFlowControl param on > https://activemq.apache.org/per-destination-policies when the value is off it > says "However, when the message store reaches capacity the producer will be > throttled until resources are freed". > > > > Thanks, > > Daniel > > > > -----Original Message----- > From: Matt Pavlovich <[email protected]> > Sent: Thursday, January 6, 2022 11:17 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. > > > > > > 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]<mailto:[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]<mailto:[email protected]>> > >> Sent: Thursday, January 6, 2022 7:42 PM > >> To: [email protected]<mailto:[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]<mailto:[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 > >> > >
