[
https://issues.apache.org/jira/browse/ARTEMIS-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
João Santos updated ARTEMIS-2891:
---------------------------------
Description:
_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_.
was:
_ActiveMQ_ possesses a _consumer.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_.
> 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)
