[
https://issues.apache.org/jira/browse/ARTEMIS-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Baert updated ARTEMIS-1858:
--------------------------------
Description:
AMQP messages that exist on node1 in a static cluster with
message-redistribution delay of 0 are not redistributed to node2, despite the
fact that node2 has a matching consumer (AMQP receiver link). The messages will
stay on the queue in node1 until they expire. There is no consumer on node1.
This issue is difficult to reproduce, most of the time the redistibution/load
balancing works as expected. It seems to happen more often under high load.
I've seen it multiple times on a 3-node Artemis cluster with 30 addresses, each
with 10 consumers (10 multicast queues) and a message rate of 1000 1KB
msg/second. Only some queues seem to be affected, though they are identical in
all but their address and name. The problem seems to occur more frequently if
the durable queues already exist (ie: the consumer has connected previously).
When 10 messages exist on node1, I see the following 10 times in the logs:
2018-05-07 14:18:59,227 WARN [org.apache.activemq.artemis.core.server]
AMQ222196: Could not find binding with id=10 on routeFromCluster for
message=AMQPMessage [durable=true, messageID=2604435, address=SomeAddress,
size=1502] binding = BindingsImpl [name=SomeAddress]
See diagram below:
!image-2018-05-09-10-26-43-971.png!
The client in use is AMQP .Net Lite. Receiver links are created such that they
behave somewhat similar to a JMS2.0 shared durable subscriber:
{code:java}
// create a receiverlink emulating a shared durable subscriber by passing the
capabilities below, and making it durable, and never expire
ReceiverLink receiver1 = new ReceiverLink(session1, "receiver1", new Source(){
Address = "orders", Capabilities = new Symbol[]{"topic", "shared", "global"},
Durable = 2, ExpiryPolicy = new Symbol("never") }, null);
{code}
It's unclear whether the specific characteristics of this link are related to
the issue.
was:
AMQP messages that exist on node1 in a static cluster with
message-redistribution delay of 0 are not redistributed to node2, despite the
fact that node2 has a matching consumer (AMQP receiver link). There is no
consumer on node1. This issue is difficult to reproduce, most of the time the
redistibution/load balancing works as expected. It seems to happen more often
under high load. I've seen it multiple times on a 3-node Artemis cluster with
30 addresses, each with 10 consumers (10 multicast queues) and a message rate
of 1000 1KB msg/second. Only some queues seem to be affected, though they are
identical in all but their address and name. The problem seems to occur more
frequently if the durable queues already exist (ie: the consumer has connected
previously).
When 10 messages exist on node1, I see the following 10 times in the logs:
2018-05-07 14:18:59,227 WARN [org.apache.activemq.artemis.core.server]
AMQ222196: Could not find binding with id=10 on routeFromCluster for
message=AMQPMessage [durable=true, messageID=2604435, address=SomeAddress,
size=1502] binding = BindingsImpl [name=SomeAddress]
See diagram below:
!image-2018-05-09-10-26-43-971.png!
The client in use is AMQP .Net Lite. Receiver links are created such that they
behave somewhat similar to a JMS2.0 shared durable subscriber:
{code:java}
// create a receiverlink emulating a shared durable subscriber by passing the
capabilities below, and making it durable, and never expire
ReceiverLink receiver1 = new ReceiverLink(session1, "receiver1", new Source(){
Address = "orders", Capabilities = new Symbol[]{"topic", "shared", "global"},
Durable = 2, ExpiryPolicy = new Symbol("never") }, null);
{code}
It's unclear whether the specific characteristics of this link are related to
the issue.
> Message Redistribution Sometimes Does Not Occur with AMQP Messages - "Could
> not find binding"
> ---------------------------------------------------------------------------------------------
>
> Key: ARTEMIS-1858
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1858
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.4.0
> Environment: RHEL, Artemis 2.4.0, AMQP .Net Lite client.
> Reporter: Todd Baert
> Priority: Major
> Attachments: image-2018-05-09-10-21-36-439.png,
> image-2018-05-09-10-26-43-971.png
>
>
> AMQP messages that exist on node1 in a static cluster with
> message-redistribution delay of 0 are not redistributed to node2, despite the
> fact that node2 has a matching consumer (AMQP receiver link). The messages
> will stay on the queue in node1 until they expire. There is no consumer on
> node1. This issue is difficult to reproduce, most of the time the
> redistibution/load balancing works as expected. It seems to happen more often
> under high load. I've seen it multiple times on a 3-node Artemis cluster with
> 30 addresses, each with 10 consumers (10 multicast queues) and a message rate
> of 1000 1KB msg/second. Only some queues seem to be affected, though they are
> identical in all but their address and name. The problem seems to occur more
> frequently if the durable queues already exist (ie: the consumer has
> connected previously).
> When 10 messages exist on node1, I see the following 10 times in the logs:
> 2018-05-07 14:18:59,227 WARN [org.apache.activemq.artemis.core.server]
> AMQ222196: Could not find binding with id=10 on routeFromCluster for
> message=AMQPMessage [durable=true, messageID=2604435, address=SomeAddress,
> size=1502] binding = BindingsImpl [name=SomeAddress]
> See diagram below:
> !image-2018-05-09-10-26-43-971.png!
> The client in use is AMQP .Net Lite. Receiver links are created such that
> they behave somewhat similar to a JMS2.0 shared durable subscriber:
> {code:java}
> // create a receiverlink emulating a shared durable subscriber by passing the
> capabilities below, and making it durable, and never expire
> ReceiverLink receiver1 = new ReceiverLink(session1, "receiver1", new
> Source(){ Address = "orders", Capabilities = new Symbol[]{"topic", "shared",
> "global"}, Durable = 2, ExpiryPolicy = new Symbol("never") }, null);
> {code}
> It's unclear whether the specific characteristics of this link are related
> to the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
