activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tbai...@gmail.com>
Subject Re: What is the correct way to throttle ActiveMQ producers who send persistent messages in batches to a queue?
Date Tue, 01 Sep 2015 13:43:01 GMT
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" <james@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message