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 > > >
