You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Egor Kalinin <ma...@ekalinin.com> on 2019/02/21 17:32:40 UTC

[ActiveMQ Artemis]: Message Groups; STOMP; idle consumers

Good day,

Protocol: STOMP
auto-create-queues, auto-create-addresses

Steps to reproduce:
1. Run two consumers which subscribe to the `test` queue ['ack': 'client',
'subscription-type': 'ANYCAST'] which are in the infinite loop take a
message from a queue, wait for 1 second and then send ACK.
2. Put 100 messages into the `test` queue ['JMSXGroupID': 'user-1',
'destination-type': 'ANYCAST']
3. Put 1 message into the `test` queue ['JMSXGroupID': 'user-2',
'destination-type': 'ANYCAST']

Expected behavior:
1. `Consumer 1` starts handling [group: user-1] immediately
2. `Consumer 2` starts handling [group: user-2] immediately

Actual behavior:
1. `Consumer 1` starts handling [group: user-1] immediately
2. `Consumer 2` waits until `Consumer 1` handled about 60 - 65 messages and
only after that starts handling [group: user-2]
(The only way to achieve expected behavior was to increase the priority of
the message in [group: user-2])

Can be reproduced even with 3 consumers, 3 message groups with 100 messages
in it (in this case `consumer 3` waits until `consumer 2` handled about 60
- 65 messages.

Please advise.

Regards,
Egor

Re: [ActiveMQ Artemis]: Message Groups; STOMP; idle consumers

Posted by Justin Bertram <jb...@apache.org>.
I believe you're seeing the expected behavior. A queue's fundamental
semantics are first-in-first-out (i.e. FIFO). Using message grouping
doesn't change those semantics. The first 100 messages in the queue (which
all belong to the same group) must be dispatched before the 101st message
is dispatched. My hunch is that the 2nd consumer is getting a message after
60-65 messages have been consumed by the 1st consumer due to messages being
dispatched from the queue to the internal, server-side consumer used by the
STOMP implementation.

Changing a message's priority *does* change the FIFO semantics of a queue
which is why you see a different behavior.


Justin

On Thu, Feb 21, 2019 at 12:33 PM Egor Kalinin <ma...@ekalinin.com> wrote:

> Good day,
>
> Protocol: STOMP
> auto-create-queues, auto-create-addresses
>
> Steps to reproduce:
> 1. Run two consumers which subscribe to the `test` queue ['ack': 'client',
> 'subscription-type': 'ANYCAST'] which are in the infinite loop take a
> message from a queue, wait for 1 second and then send ACK.
> 2. Put 100 messages into the `test` queue ['JMSXGroupID': 'user-1',
> 'destination-type': 'ANYCAST']
> 3. Put 1 message into the `test` queue ['JMSXGroupID': 'user-2',
> 'destination-type': 'ANYCAST']
>
> Expected behavior:
> 1. `Consumer 1` starts handling [group: user-1] immediately
> 2. `Consumer 2` starts handling [group: user-2] immediately
>
> Actual behavior:
> 1. `Consumer 1` starts handling [group: user-1] immediately
> 2. `Consumer 2` waits until `Consumer 1` handled about 60 - 65 messages and
> only after that starts handling [group: user-2]
> (The only way to achieve expected behavior was to increase the priority of
> the message in [group: user-2])
>
> Can be reproduced even with 3 consumers, 3 message groups with 100 messages
> in it (in this case `consumer 3` waits until `consumer 2` handled about 60
> - 65 messages.
>
> Please advise.
>
> Regards,
> Egor
>