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