[jira] [Updated] (ARTEMIS-2004) [AMQP] address-full-policy block should drain the link credit of attached sending links when the address becomes full

["Keith Wall (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARTEMIS-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Keith Wall updated ARTEMIS-2004:
--------------------------------
    Description: 
As described by the [flow control documentation|https://activemq.apache.org/artemis/docs/latest/flow-control.html#blocking-amqp-producers], the broker will stop issuing credits once an address is full.  This means however, that existing senders can continue to utilise the existing credit they hold for sending more messages, potentially taking the address far beyond {{max-size-bytes}} or the Broker beyond {{global-max-size}} values.

A potential improvement would be to have the Broker send, on the address becoming full, a {{flow}} performative carrying the {{drain=true}} field.  This would instruct the sender to send up to the existing link-credit pending messages and then reduce link-credit to zero, thus preventing it from sending any more.  This would serve to minimise the extent to which the address or broker can grow beyond their configured maximum values.

I did notice the address specific {{max-size-bytes-reject-threshold}} setting.  This works for the use-case where you can predict in advance the address's desired upper size, but works less well when trying to restrict the cumulative size of the all the addresses on the Broker (as might be desired by those offering the Broker as part of a managed service).

  was:
As described by the [flow control documentation|https://activemq.apache.org/artemis/docs/latest/flow-control.html#blocking-amqp-producers], the broker will stop issuing credits once an address is full.  This means however, that existing senders can continue to utilise the existing credit they hold for sending more messages, potentially taking the address far beyond {{max-size-bytes}} or the Broker beyond {{global-max-size}} values.

A potential improvement would be to have the Broker send, on the address becoming full, a {{flow}} performative carrying the {{drain=true}} field.  This would instruct the sender to send up to the existing link-credit pending messages and then reduce link-credit to zero, thus preventing it from sending any more.  This would serve to minimise the extent to which the queue or broker can grow beyond their configured maximum values.

I did notice the address specific {{max-size-bytes-reject-threshold}} setting.  This works for the use-case where you can predict in advance the address's desired upper size, but works less well when trying to restrict the cumulative size of the all the addresses on the Broker (as might be desired by those offering the Broker as part of a managed service).


> [AMQP] address-full-policy block should drain the link credit of attached sending links when the address becomes full
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARTEMIS-2004
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2004
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>            Reporter: Keith Wall
>            Priority: Major
>
> As described by the [flow control documentation|https://activemq.apache.org/artemis/docs/latest/flow-control.html#blocking-amqp-producers], the broker will stop issuing credits once an address is full.  This means however, that existing senders can continue to utilise the existing credit they hold for sending more messages, potentially taking the address far beyond {{max-size-bytes}} or the Broker beyond {{global-max-size}} values.
> A potential improvement would be to have the Broker send, on the address becoming full, a {{flow}} performative carrying the {{drain=true}} field.  This would instruct the sender to send up to the existing link-credit pending messages and then reduce link-credit to zero, thus preventing it from sending any more.  This would serve to minimise the extent to which the address or broker can grow beyond their configured maximum values.
> I did notice the address specific {{max-size-bytes-reject-threshold}} setting.  This works for the use-case where you can predict in advance the address's desired upper size, but works less well when trying to restrict the cumulative size of the all the addresses on the Broker (as might be desired by those offering the Broker as part of a managed service).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)