[
https://issues.apache.org/jira/browse/ARTEMIS-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leo Provido updated ARTEMIS-2252:
---------------------------------
Description:
We’ve encountered what we think is a bug in Artemis. The issue arises
establishing two AMQP receiver links to the same Artemis queue (durable), where
each receiver link is established with an AMQP “filter set”, and then messages
are sent to the queue where those messages are assigned to message groups. The
messages are filtered on message type (JMSType). With this setup, we
occasionally find that Artemis permanently holds onto a message (i.e. never
delivers it).
We send 100,000 messages (of the same type – all messages go to the same
receiver link) to the queue, where each message is assigned to one of 10,000
message groups, where each message group contains 10 messages. Furthermore, the
messages are assigned to message groups in the order such that:
• After the first 10,000 messages have been sent, each message group has
been assigned one message
• After the second 10,000 messages have been sent, each message group has
been assigned two messages
• After 90,000 message have been sent, each message group has been
assigned 9 messages.
The client application creating the two receiver links accepts all messages in
a message group when the last message in that message group is received.
We find the client application sometimes receives fewer than 100,000 messages
from Artemis. Around 1 in 3 the application receives 99,999 messages, but
sometimes, even fewer than 99,999 messages. After 2 minutes, we time out the
message group containing the one missing message and reject the 9 messages we
did receive. This then leaves one message in the queue.
This message is never delivered. However, more interestingly, when we then
attempt to close the connection, it takes 60 seconds to close. Furthermore,
after 30 seconds, Artemis logs a thread dump. After another 30 seconds, Artemis
logs a second thread dump, and then the connection is closed. The attached is a
copy of both thread dumps.
Note that if the second receiver link is not created, the issue does not occur.
was:
We’ve encountered what we think is a bug in Artemis. The issue arises
establishing two AMQP receiver links to the same Artemis queue (durable), where
each receiver link is established with an AMQP “filter set”, and then messages
are sent to the queue where those messages are assigned to message groups. The
messages are filtered on message type (JMSType). With this setup, we
occasionally find that Artemis permanently holds onto a message (i.e. never
delivers it).
We send 100,000 messages (of the same type – all messages go to the same
receiver link) to the queue, where each message is assigned to one of 10,000
message groups, where each message group contains 10 messages. Furthermore, the
messages are assigned to message groups in the order such that:
• After the first 10,000 messages have been sent, each message group has
been assigned one message
• After the second 10,000 messages have been sent, each message group has
been assigned two messages
• After 90,000 message have been sent, each message group has been
assigned 9 messages.
The client application creating the two receiver links accepts all messages in
a message group when the last message in that message group is received.
We find the client application sometimes receives fewer than 100,000 messages
from Artemis. Around 1 in 3 the application receives 99,999 messages, but
sometimes, even fewer than 99,999 messages. After 2 minutes, we time out the
message group containing the one missing message and reject the 9 messages we
did receive. This then leaves one message in the queue.
This message is never delivered. However, more interestingly, when we then
attempt to close the connection, it takes 60 seconds to close. Furthermore,
after 30 seconds, Artemis logs a thread dump. After another 30 seconds, Artemis
logs a second thread dump, and then the connection is closed. The attached is a
copy of both thread dumps.
> Some messages are never delivered.
> ----------------------------------
>
> Key: ARTEMIS-2252
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2252
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.6.4
> Reporter: Leo Provido
> Priority: Major
> Attachments: Artemis 2.6.4 thread dump.txt
>
>
> We’ve encountered what we think is a bug in Artemis. The issue arises
> establishing two AMQP receiver links to the same Artemis queue (durable),
> where each receiver link is established with an AMQP “filter set”, and then
> messages are sent to the queue where those messages are assigned to message
> groups. The messages are filtered on message type (JMSType). With this setup,
> we occasionally find that Artemis permanently holds onto a message (i.e.
> never delivers it).
> We send 100,000 messages (of the same type – all messages go to the same
> receiver link) to the queue, where each message is assigned to one of 10,000
> message groups, where each message group contains 10 messages. Furthermore,
> the messages are assigned to message groups in the order such that:
> • After the first 10,000 messages have been sent, each message group has
> been assigned one message
> • After the second 10,000 messages have been sent, each message group has
> been assigned two messages
> • After 90,000 message have been sent, each message group has been
> assigned 9 messages.
> The client application creating the two receiver links accepts all messages
> in a message group when the last message in that message group is received.
> We find the client application sometimes receives fewer than 100,000 messages
> from Artemis. Around 1 in 3 the application receives 99,999 messages, but
> sometimes, even fewer than 99,999 messages. After 2 minutes, we time out the
> message group containing the one missing message and reject the 9 messages we
> did receive. This then leaves one message in the queue.
> This message is never delivered. However, more interestingly, when we then
> attempt to close the connection, it takes 60 seconds to close. Furthermore,
> after 30 seconds, Artemis logs a thread dump. After another 30 seconds,
> Artemis logs a second thread dump, and then the connection is closed. The
> attached is a copy of both thread dumps.
> Note that if the second receiver link is not created, the issue does not
> occur.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
