activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martyn Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARTEMIS-627) Producer Block does work properly on CORE protocol
Date Wed, 13 Jul 2016 09:44:20 GMT

    [ https://issues.apache.org/jira/browse/ARTEMIS-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374729#comment-15374729
] 

Martyn Taylor commented on ARTEMIS-627:
---------------------------------------

When you say set flow control = 1.  Do you mean set the producer window size = 1.  Given that
the window size represents max transfer in bytes, how would issuing 1 credit at a time perform?

Not sending credits to a client does not BLOCK on the address as I explained above.  If the
behaviour is intentional which I believe it is since it's always been this way, then we need
to at the very least update the docs to reflect the actual behaviour.  Preferably the BLOCK
would behave as outlined in the docs, which does require some changes.





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

Mime
View raw message