[
https://issues.apache.org/jira/browse/ARTEMIS-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191347#comment-17191347
]
João Santos edited comment on ARTEMIS-2891 at 9/6/20, 5:52 PM:
---------------------------------------------------------------
Another question I would ask is, what unit do we want to keep in Artemis?
ActiveMQ _activemq.prefetchSize_ uses amount of messages in units, regardless
of their size, while Artemis _stompConsumerCredits_ seems to use the total
messages size in bytes. In my opinion, the amount of messages is much more
meaningful for a client/consumer implementation than the total message size in
bytes. However, from security stand point, the _stompConsumerCredits_ is a far
better approach as it limits the amount of bytes which can be send into
client's/consumer's memory, thus protecting them from overflowing.
Maybe the best option would be to support both. A __ _prefecthSize_ header in
the STOMP SUBSCRIBE packet, would control the maximum amount of messages (in
units) that this client/consumer may retrieve from the broker without
acknowledging them. On the other hand, the _stompConsumerCredits_ server-side
acceptor configuration would prevent the delivery of more than a defined total
message size (in bytes) per consumer.
This would consumer memory safety under environments where the messages content
is highly uncontrolled but also allow them to define the maximum amount of
messages they wish to receive, which may vary depending on the consumer
purpose/implementation.
*Note:* The _activemq.prefetchSize_ header could be kept as a synonym for
_prefetchSize_ header, in order to provide a simpler migration path from AMQ5
to AMQ Artemis, and be deprecated later.
was (Author: rtista):
Another question I would ask is, what unit do we want to keep in Artemis?
ActiveMQ _activemq.prefetchSize_ uses amount of messages in units, regardless
of their size, while Artemis _stompConsumerCredits_ seems to use the total
messages size in bytes. In my opinion, the amount of messages is much more
meaningful for a client/consumer implementation than the total message size in
bytes. However, from security stand point, the _stompConsumerCredits_ is a far
better approach as it limits the amount of bytes which can be send into
client's/consumer's memory, thus protecting them from overflowing.
Maybe the best option would be to support both. A __ _prefecthSize_ header in
the STOMP SUBSCRIBE packet, would control the maximum amount of messages (in
units) that this client/consumer may retrieve from the broker without
acknowledging them. On the other hand, the _stompConsumerCredits_ server-side
acceptor configuration would prevent the delivery of more than a defined total
message size (in bytes) per consumer.
This would consumer memory safety under environments where the messages content
is highly uncontrolled but also allow them to define the maximum amount of
messages they wish to receive, which may vary depending on the consumer
purpose/implementation.
> 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)
