Hello there, I have a problem that might be a little difficult to grasp, but I will try to explain it.
I have a composite queue "cq" on "routerY", that writes into a local queue "ql" and into a remote queue "qr@routerX" (change destination is ticked for this queue). Then there is JMS bridge that reads "qr@routerX" and puts the message into another queue "qz@routerZ" - this router is not a member of the router network that routerY and routerX are in.
So now let's look at a producer. I have a producer that is connected to "routerY" and writes into the composite queue "cq". As you would expect the consumer, that reads "ql" gets the message, also the consumer that reads "qz" on routerZ gets the message and all is well.
Now let's look at another producer, that is connected to routerX. This producer writes directly into "cq@routerY". Now the consumer that reads "ql" from routerY sees the message, but the message to "qz@routerZ" is lost somewhere on the way. My first idea was that the duplicate message detection removes it when it is delivered to "qr@routerX" because routerX has already seen the message when the producer put it into "cq@routerY". So I ticked "generate new message id" in the composite queue for "qr@routerX", but to no avail. I then also unchecked "Duplicate detection enabled" for the queue "qr" on routerX, but still to no avail.
As there is a fair amount of messages that is delivered this way it is hard to see just from the message counter of the JMS bridge on routerZ or the queue counter of "qr" if the message has ever reached one of these checkpoints, but it never reaches the final consumer. Do you have any idea why this happens or how I would be able to trace the message to see when, where and why it is lost?
Any help would be greatly appreciated!
I can think of a workaround with a freshly created composite queue on routerX, that would also eliminate the "problem" with the message travelling back and forth in the first place, but I would rather understand the initial problem.
So what you are not seeing is a message sent from X and traveling back to X?
A message that is sent to a comp queue is distributed as follows:
- The first link gets the original
- The next links gets a copy
Routing automatically avoids that messages sent from a source router will be sent to the same router again as this would be open the door for infinite loops. I think this happened here because the original message should be sent to the router where it came from.
Yes, the messages was produced on routerX but never put into a local queue. It then travelled to a composite queue on routerY that has a target queue back on routerX. I would expect the message to be delivered nevertheless, but if you say this is not possible and will never be because of the risk involved, I will go with my workaround, that is more traffic efficient anyway.
I did just notice one thing, while checking the contents of the different rt$routername queues because of other performance and lookup issues, some messages are indeed bouncing back and forth, as it would seem. This is a little odd, as I see no reason why router X should put them back into rt$routerY if the destination is local. Nevertheless I tried to move them into another queue but never seem to manage to get a hold of them. They are always locked and my move command always fails.
EDIT: I managed to get rid of the messages using the exact same move command. The problem was, the messages were always locked. So how do I get rid of that lock? Stopping the routing connectors did not help, they remained locked, which was unfortunate. But stopping the routing for a long enough time increase the amount of messages on rt$routerY that I was then able to grab some of the messages while others were locked and they weren't. Repeated this until none were left. This does not sound like the best method to achieve this, though ;)
Hmmm... May be it has something to do with the composite queues? Please check that you don't send to a comp queue from a remote router that returns a message to the same router. I haven't tested it but it might be lead to some kind of ping-pong.
I am sure it has something to do with the composite queues, but the result was unexpected. From your comment I figured the message should be discarded, otherwise I would have expected local delivery instead of pingpong, but I got rid of the messages and will keep the issue in mind for further composite queue constructs.