activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <>
Subject [jira] [Commented] (ARTEMIS-627) Producer Block does work properly on CORE protocol
Date Thu, 14 Jul 2016 10:54:20 GMT


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:
>             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

View raw message