Queue sub may not receive message in leafnode daisy-chain and gateway setups #6125
Assignees
Labels
defect
Suspected defect such as a bug or regression
Comments
derekcollison
added a commit
that referenced
this issue
Nov 13, 2024
) In complex setup, a message produced from a cluster that had queue interest from leafnodes (either hub or spoke) would sometimes not deliver a message if the interest was a leafnode that had the interest on behalf of a gateway. In the setup described in the issue this PR fixes, "Cluster B" may have picked "Cluster C", but that cluster does not have local queue interest, only the leafnode interest from "Cluster B", and would pick a LEAF connection to this cluster, but then suppress the message since it came from "B" so "C" cannot send it back there. But picking a queue sub for "B" in "C" would then prevent the message to be delivered to the gateway "D". Resolves #6125 Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
neilalexander
pushed a commit
that referenced
this issue
Nov 14, 2024
In complex setup, a message produced from a cluster that had queue interest from leafnodes (either hub or spoke) would sometimes not deliver a message if the interest was a leafnode that had the interest on behalf of a gateway. In the setup described in the issue this PR fixes, "Cluster B" may have picked "Cluster C", but that cluster does not have local queue interest, only the leafnode interest from "Cluster B", and would pick a LEAF connection to this cluster, but then suppress the message since it came from "B" so "C" cannot send it back there. But picking a queue sub for "B" in "C" would then prevent the message to be delivered to the gateway "D". Resolves #6125 Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Observed behavior
In the following setup:
If there are queue subscribers on "foo" for queue "queue" attached to "Cluster A" and "Cluster D", and a message is published on "Cluster B", the message will be delivered to one of the queue subscriber on "Cluster A" but sometimes, none of the queue subscriber on "Cluster A" will receive it, and "Cluster D" queue subscribers never receive any message.
Expected behavior
Since there is a queue subscription interest in both "Cluster A" and "Cluster D", message should either go to "A" or "D" but not be dropped.
Server and client version
Latest versions.
Host environment
n/a
Steps to reproduce
Create the setup described above and publish message and notice that sometimes a message does not make it to the queue subs.
The text was updated successfully, but these errors were encountered: