[
https://issues.apache.org/jira/browse/ARTEMIS-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15376636#comment-15376636
]
Martyn Taylor commented on ARTEMIS-627:
---------------------------------------
I don't believe multiple producers sending to the same address is a corner
case. I would say it's a quite viable pattern that applications may use. I'm
not sure I agree with your comment about the fix having detrimental impact on
performance. We could just as easily add a configuration option (or a new
AddressFullPolicy.STRICT_BLOCK or similar) that covers the existing behaviour
and the behaviour outlined in the docs. Any performance implication would only
take affect for those cases where the "STRICT BLOCK" policy is enabled and the
impact could be documented. Mostly my concern right now is that actual
behaviour and what is outlined in the docs is quite different and misleading to
users, in addition to the implications of doing the flow control on the client
side are not obvious to users.
I'm happy to update the docs to explain how this works right now and what the
vunerabilities are. I'll update this JIRA to a feature request to implement
"STRICT BLOCK" and we can address it if/when users ask for it.
> 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: Bug
> 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)
