[
https://issues.apache.org/jira/browse/ARTEMIS-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15376778#comment-15376778
]
Martyn Taylor commented on ARTEMIS-627:
---------------------------------------
[~gemmellr]
"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."
I have no issue with this as a policy. But, it's not what is described in the
documentation and not what has been advertised as the BLOCK behaviour for some
time. I'm not arguing against offering this approach as an option, but there
may well be users who have implemented applications with a strict block policy
(as outlined in the docs) in mind. My main concern is consistency, we can
address that by updating the doc.
"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."
Clebert's comments:
"Fixing this would be serious impact in performance, just to satisfy corner
cases where you could have multiple producers."
"Performance would be inviable to implement the feature in such way. And even
so it's not worth the implementation."
I don't beleive that a STRICT BLOCK policy is inviable to implement and
performance hit could be restricted only to those users who require this
feature; who would be aware of the performance implications of switching this
on. A use case for this may be where a broker is exposed in a public domain
say in a SaaS deployment (or any case where clients are not trusted) or a bug
in application code, in these cases it may be necessary to protect the broker
(and other applications using the broker) in times of high load, at the expense
of lowering performance for specific applications.
"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."
Yes, I believe offering two policy types is a good way to satisfy both
requirements.
> 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)
