|
Message staying in rt$routernamedest
Hello,
We have 3 routers connected toghether, A,B and C. Moving messages from router A to router C through router B (A is connected to B, and B to C, no direct connection from A to router C) result in some cases, in message not delivered to the corresponding queue, and stay in rt$C, and disapear slowly from rt$B.
How can we have messages correctly delivered, and worth, how can we have a rt$C that decrease naturally ?
Thanks for your support.
|
|
Re: Message staying in rt$routernamedest
As explained before there is a bug in moving messages (CLI move) which have been routed already. See my reply on the other message. Avoid that move until fixed.
|
|
Re: Message staying in rt$routernamedest
Not in this case.
We have not moved messages from A to B and then B to C.
We have scheduled a move from A directly to C (only one so). but messages passes through router B, as A and C are not interconnected.
|
|
Re: Message staying in rt$routernamedest
I understand but it doesn't matter through how many hops a message travel.
How do you send the messages from A to C? By using Queue Mover Job? Are the messages produced to the queue at A are produced by a client directly connected to A or are they routed to A from other routers?
|
|
Re: Message staying in rt$routernamedest
messages are produced on router A and then moved with a queue mover to a queue@routerC with a scheduler on router A (as a scheduler on router C cannot pick up a message on C)
We have a lot of trouble getting ALL messages on C, and a rt$C empty.
|
|
Re: Message staying in rt$routernamedest
Just tested it with 3 routers:
router1<-router2<-router3
Sending 1MM messages to testqueue@router1 and had a Queue Mover Job with source queue testqueue@router1, target queue testqueue@router3 defined which runs every 2 min. All messages were successfully moved to router3, no stuck in any rt$ queue.
If you need further assistance, you might file a Gold incident.
|
|
Re: Message staying in rt$routernamedest
rt$isis_int is router A
rt$isis_ext is router B were this count is produced
rt$RouterPacProd is router C
========================================
rt$RouterPacProd
========================================
Date Queue Nb messages Evol P-1 max(P-1)
2009.09.10-01.06 rt$RouterPacProd 6321
2009.09.10-02.06 rt$RouterPacProd 5231 -1090 5994
2009.09.10-03.06 rt$RouterPacProd 4539 -692 5154
2009.09.10-04.06 rt$RouterPacProd 3856 -683 4556
2009.09.10-05.06 rt$RouterPacProd 3842 -14 3869
2009.09.10-06.06 rt$RouterPacProd 2987 -855 3355
2009.09.10-07.06 rt$RouterPacProd 2333 -654 2941
2009.09.10-08.06 rt$RouterPacProd 2159 -174 2522
2009.09.10-09.06 rt$RouterPacProd 2074 -85 2300
2009.09.10-10.06 rt$RouterPacProd 1498 -576 1856
2009.09.10-11.06 rt$RouterPacProd 1680 182 1690
2009.09.10-12.06 rt$RouterPacProd 416 -1264 1981
2009.09.10-13.06 rt$RouterPacProd 705 289 705
2009.09.10-14.06 rt$RouterPacProd 203 -502 708
2009.09.10-15.06 rt$RouterPacProd 420 217 664
2009.09.10-15.56 rt$RouterPacProd 799 379 799
========================================
rt$isis_int
========================================
Date Queue Nb messages Evol P-1 max(P-1)
2009.09.10-01.06 rt$isis_int 0
2009.09.10-02.06 rt$isis_int 0
2009.09.10-03.06 rt$isis_int 0
2009.09.10-04.06 rt$isis_int 0
2009.09.10-05.06 rt$isis_int 0
2009.09.10-06.06 rt$isis_int 0
2009.09.10-07.06 rt$isis_int 0
2009.09.10-08.06 rt$isis_int 2 2 2
2009.09.10-09.06 rt$isis_int 2 0 10
2009.09.10-10.06 rt$isis_int 5 3 5
2009.09.10-11.06 rt$isis_int 0 -5 2
2009.09.10-12.06 rt$isis_int 0
2009.09.10-13.06 rt$isis_int 0
2009.09.10-14.06 rt$isis_int 0
2009.09.10-15.06 rt$isis_int 0
2009.09.10-15.56 rt$isis_int 0
|
|
Re: Message staying in rt$routernamedest
May be it's just flow control and you have a slow consumer on the destination queue. Do you see a FC Delay on your destination queue?
|
|
Re: Message staying in rt$routernamedest
FC Delay on destination queue is 0
FC Delay on Router C is 5000
as you saw, from router B, there is an rt$C that is decreasing, but as seen from router C, rt$C is 20030, and fluctuating strangely, but still this high.
|
|
Re: Message staying in rt$routernamedest
What means "FC Delay on Router C is 5000"? Can you post some Explorer screenshots?
|
|
Re: Message staying in rt$routernamedest
Sorry, FC Delay is 5000 on rt$C seen on router C
|
|
Re: Message staying in rt$routernamedest
You mean on router B?
Did you try to move messages from router C to other routers?
|
|
Re: Message staying in rt$routernamedest
No, it can be seen on router C. and sorry, it is seen as rt$B
And no, there is no other move, as it do not work.
Checking the generation, we have in fact:
Messages are generated on router A, on a topic.
Messages are moved by a scheduler to a queue on router C from a durable subscriber.
Messages are consumed from a queue by an application on a server that carry router C
|
|
Re: Message staying in rt$routernamedest
rt$C cannot be on router C because it is the routing queue _for_ router C so it must be located on B.
I've just tested the combination to move the messages from a durable subscriber queue and it worked fine. So without any further investigation (like tracing), which is out of scope of this forum, I have to quit. Please file an incident.
|
|
Re: Message staying in rt$routernamedest
Btw, why don't you just create the durable subscriber on router C? You can publish on any node and message distribution is automatically. You won't need move messages at all..
|
