On 6/24/24 02:56, Saju Daniel wrote:
Hello Tim ,

Were you able to reproduce the issue with the messages in Delivering state
in the federated queue ?
Please let me know if you need more information .

I have not seen a reproducer provided so I have not looked into this further.

My suggestion would be to try with the newer AMQP federation configured using the latest 2.35.0 release.



Regards,
Saju

On Fri, 21 Jun 2024 at 11:57, Saju Daniel <dsa...@gmail.com> wrote:

Hello ,

I tried out the same scenario with the version 2.35 and still see the
issue that federated queue shows the message in delivering state even
though its correctly delivered at the other end .
I hope you are able to reproduce this at your end as well.

For illustration below is the status at both cluster endpoints .

*Status of queue on EU cluster with federated queue*

NAME

ADDRESS

CONSUMER  COUNT

MESSAGE  COUNT

MESSAGES  ADDED

DELIVERING  COUNT

MESSAGES  ACKED

SCHEDULED  COUNT

  ROUTING  TYPE

INTERNAL

federated.us-dev.eu-dev.events.name.v1.seminars.multicast

events.name.v1.seminars

1

2

2

2

0

0

MULTICAST

  false





*Status of queue on US cluster with consumer queue*

NAME

ADDRESS

CONSUMER COUNT

  MESSAGE  COUNT

MESSAGES ADDED

DELIVERING COUNT

MESSAGES ACKED

   COUNT

  ROUTING TYPE

INTERNAL

audit-trail-shared

events.#

5

0

2

0

2

0

MULTICAST

  false

Regards,
Saju


On Thu, 20 Jun 2024 at 20:44, Timothy Bish <tabish...@gmail.com> wrote:

On 6/20/24 12:50, Saju Daniel wrote:
Hello Tim,

Thanks for the reply . We figured out the reason for duplicate message .

It was caused by the wildcard entry we used on federation configuration
. This was because the wild card address was also an address queue on the
Europe cluster. i.e events.#.
The consumer at the USA ends up receiving 2 messages because when we
enable Federation on Europe cluster we saw that it created 2  federated
addresses for the same consumer on Europe side. 1 with the complete address
e.g events.name.v1.seminars  and another with the wildcard events.#.
We resolved it by having the wildcard in broker.xml to be events.name.#.

But we see that the federated queue messages are only with status
‘Delivering’  and not in acknowledged state . Is this expected ? Will these
delivering message ever get deleted ? Is there a way these messages can be
marked acknowledged because the consumer at the USA cluster was
successfully  able to consume the message and it’s marked acknowledged on
the consumer queue.

It sounds odd, and could be a bug in the core federation but we'd need a
way to reproduce to investigate this.



Best regards,
Saju Daniel

On 20. Jun 2024, at 16:55, Timothy Bish <tabish...@gmail.com> wrote:

On 6/19/24 14:33, Saju Daniel wrote:
Hello All ,

We see duplicated message at the consumer end on USA federation with a
symmetric federation  setup as described here -

https://activemq.apache.org/components/artemis/documentation/2.20.0/federation-address.html
The configuration is described in the stackoverflow query here:


https://stackoverflow.com/questions/78633745/is-upstream-config-bidirectional-on-address-federation-with-symetric-topology-be?noredirect=1#comment138634573_78633745
Could someone kindly take a quick look and see if there is something
wrong
in the configuration and why we are seeing duplicated messages .

Regards,
Saju

If your setup configures the various nodes to use max-hops correctly I
would not expect duplicates. I tried reproducing it and could not so I'd
suggest creating an reproducer that you can share to allow for
investigation.  What version of Artemis are you using? Have you tried the
latest release?
Another option would be to make use the AMQP federation using broker
connections which was introduced in v2.31.0 and steadily improved since
that release.

https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html#federation
--
Tim Bish


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org
For additional commands, e-mail: users-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org
For additional commands, e-mail: users-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact


--
Tim Bish


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org
For additional commands, e-mail: users-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact




--
Tim Bish


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org
For additional commands, e-mail: users-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact


Reply via email to