[
https://issues.apache.org/jira/browse/ARTEMIS-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15376792#comment-15376792
]
Martyn Taylor commented on ARTEMIS-627:
---------------------------------------
[~gemmellr] Sure, thanks Robbie. I can certainly see how the current behaviour
is a good middle ground between performance and protecting the broker. I just
wanted to make sure we don't just shut this down and ignore it because it can
hurt performance. I did some testing and it's quite easily to exhaust the
brokers memory with a single dodgy client. I'll get the doc updated and we can
address this as a feature request later down the line.
I'm in the process of adding BLOCK for AMQP, we could easily add reject to the
BLOCK policy. Using amqp:resource-limit-exceeded, I guess it's a little more
important with AMQP since the flow control credits represent number of messages
(vs number of bytes as in CORE) so it could be possible to go way over the
limit quite quickly. Do you have any thoughts on what would be best in teh
AMQP scneario?
Thanks
> 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)
