[
https://issues.apache.org/jira/browse/ARTEMIS-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15376760#comment-15376760
]
Robbie Gemmell commented on ARTEMIS-627:
----------------------------------------
What you described is how I've seen this work in some other cases too,
effectively a soft limit where the producers get asked to stop as its crossed
but any in-progress asynchronous work done before the producers can receive the
notification is allowed to complete. They then get told to resume as things
drop below [a possibly lower] threshhold again.
That has issues as you describe, the 'limit' can be breached due to the things
in flight already, and even more so in the case of multiple producers due to
the combined effect of that. The upside is that producer apps/clients only need
to handle blocking/not being able to send initially, versus handling things
they already sent failing [perhaps asynchronously] due to the limit being hit.
For many folks thats enough, helping govern things significantly but not to an
exact point, whereas others folks might need/want stricter behaviour.
Clebert thoughts about performance implication are likely accurate, since in
the 'soft limit' case nothing ever needs rejected and resent (if the sender can
actually handle that, rather than just stopping due to the failures) and there
is likely to be less stopping and starting, keeping throughput higher.
The suggestion of having two modes seems reasonable as that way folks can pick
what behaviour they want. Another option is a hybrid employing both aspects,
where theres the soft limit thats used for the typical governing and also a
hard limit to bound the worst case overshoot.
> Producer Block does work properly on CORE protocol
> --------------------------------------------------
>
> Key: ARTEMIS-627
> URL: https://issues.apache.org/jira/browse/ARTEMIS-627
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Reporter: Martyn Taylor
>
> To BLOCK production of messages to an address once it reaches a particular
> size in memory, an AddressSetting can be added to the broker that specifies
> the address size, address match string and the address full policy "BLOCK".
> This should block messages once the address is full, however the current
> implementation uses flow control to allocate producers credits, once the
> address is full the broker will not allocate any more credits.
> There are two issues with this approach.
> 1. The main issue is that the credits are not tracked or checked at the
> broker side. The ActiveMQ client takes care of blocking message production
> when it runs out of credit. However, a rogue client could easily allocate
> it's own credits and continue sending. I've tested this by hacking the
> client and it behaves in this way.
> 2. Even in a non hacked client the size of the address could be pushed over
> it's limit, as more credits can be allocated than is available space on the
> address. An address can be full, no more credits are allocated but each
> producer is able to empty it's credits pushing the address over its limit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
