James, There are two independent concepts here: 1. what limit gets evaluated to determine whether the producer should stop sending messages 2. which producers should be stopped in response
Without ProducerWindowSize, the limits are based on the destination and the entire store (plus other limits such as memoryUsage), and the options for who to stop are to stop only the producer that is sending to a PFCed destination (but not other producers on the same connection unless they also publish to a PFCed destination) or all producers on the connection even if they are publishing to destinations that are not PFCed. Without ProducerWindowSize, the terms "per-producer" and "whole-connection" unambiguously refer to #2, the action to take in response. ProducerWindowSize adds a per-producer option to #1, the limits to evaluate, and I should have disambiguated between the two. To be clear, when I said "per-producer PFC" in this thread, I was referring only to #2, and I believe the same is true of the wiki (though I'm going from memory here so I could be wrong). As far as actually configuring ProducerWindowSize, it needs to be set small enough that your producer hits the window size by the time the destination gets full, otherwise it'll have no effect. For a single producer on a given destination, just set ProducerWindowSize to the destination limit. For multiple producers on a destination, a safe value is the destination limit / number of producers. You can increase it if you have guarantees that let you say that your producers won't all hit their limits at once (no matter how long consumers are down and no matter what else happens on the broker), but you'd better be very sure about those guarantees or you won't be sure you'll hit the ProducerWindowSize before whole-connection PFC kicks in. I've got one question about this most recent email, though. Why is it bad to see that the "Producers will be throttled" message was immediately followed by "Producer stopped"? Stopping the producer immediately is the point of PFC. Also, you said "Eventhough the Producer was not stopped immediately in my case, I found that the Producer was stopped eventually after testing it for a prolonged period of time (> 8 hours)." I suspect that this was the point where you had filled both the broker's TCP receive buffer and your producer's TCP send buffer, at which point your TCP send() calls will hang. Tim On Aug 31, 2015 10:04 PM, "jamesTheCruncher" <ja...@mcruncher.com> wrote: > Hi Tim, > > Thanks for your continued interest in this subject. > Yes, as per my testing, I didn't configure any ProducerWindowSize but found > that the PFC was kicking in based on the per-destination limit I > configured. > I don't think it was the whole-connection PFC because I had set fairly > larger limits for system usage. > From the logs, I found that the parent usage didn't hit even 1 percentage. > > > But I noticed that the "Producers will be throttled" message was > immediately > followed by "Producer stopped" in the logs, which makes me to think that > one > should configure a ProducerWindowSize value that is less than the > per-destination limit set. > > Eventhough the Producer was not stopped immediately in my case, I found > that > the Producer was stopped eventually after testing it for a prolonged period > of time (> 8 hours). > > I will configure ProducerWindowSize and continue my testing. But it will be > great if someone can tell whether my "guessing" is correct and whether I am > proceeding in the right direction. > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/What-is-the-correct-way-to-throttle-ActiveMQ-producers-who-send-persistent-messages-in-batches-to-a--tp4701204p4701571.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
