[jira] [Resolved] (ARTEMIS-2891) Allow configuring stompConsumerCredits variable from client side (consumer)

["Justin Bertram (Jira)" <ji...@apache.org>]

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

Justin Bertram resolved ARTEMIS-2891.
-------------------------------------
    Resolution: Duplicate

Flow control is Artemis is based on *bytes* rather than messages. The STOMP implementation is no different. I won't be implementing flow control based on message count for this issue.

I will be implementing a new header named {{consumer-window-size}} for the `SUBSCRIBE` frame to be consistent with naming from other areas of the broker as well as the core and JMS client implementations. The {{activemq.prefetchSize}} will be supported for backwards compatibility.

I'm closing this issue as a duplicate of ARTEMIS-589. 

> Allow configuring stompConsumerCredits variable from client side (consumer)
> ---------------------------------------------------------------------------
>
>                 Key: ARTEMIS-2891
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2891
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>          Components: STOMP
>            Reporter: João Santos
>            Assignee: Justin Bertram
>            Priority: Major
>
> _ActiveMQ_ possesses a _activemq.prefetchSize_ client-side configurable parameter (via STOMP headers) which provides a way to configure the amount of messages which can be retrieved by the client without acknowledging the message reception.
> Current implementation of _Artemis_ does not allow this behavior and instead only allows to set the _stompConsumerCredits,_ the maximum size in bytes which may be received by the consumer as messages, from server-side configuration in broker.xml. This represents a functionality loss for customers migrating from _ActiveMQ_ to Artemis as _stompConsumerCredits_ works based on message size in bytes and not message units and since it is not configurable via client-side STOMP headers.
> This is unexpected since a consumer, depending on the processing, might want to retrieve a batch of messages in order to bulk process them for better performance (_i.e._ retrieving log messages from queue and storing them into a database, bulk inserting will be much faster than 1 by 1 inserts). In other cases, the consumer might want to only receive one message at most before acknowledging and so this parameter should be configurable from client-side in order to better adapt to the consumer processing and to achieve a more complete feature parity with _ActiveMQ Classic_.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)