]
Bela Ban commented on JGRP-1539:
--------------------------------
OK, so anectotal evidence (small MPerf run with 2 nodes and 1 million 1K messages each)
suggests:
- before: 263 / 164 retransmission requests (udp.xml)
- after: 4 / 3 retransmission requests (udp.xml)
- before: 118 / 0 retransmission requests (fast.xml)
- after: 0 /0 retransmission requests (fast.xml)
NAKACK2: xmit_interval sometimes triggers unneeded retransmissions
------------------------------------------------------------------
Key: JGRP-1539
URL:
https://issues.jboss.org/browse/JGRP-1539
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
In NAKACK2 (and UNICAST2 as well), a timer task kicks in every xmit_interval
milliseconds. If we just added a message out of order, then the retransmit task might send
a spurious retransmission message.
Example:
- Messages 1,2,3,4,5 are received at time T0 (in ms)
- At time T1000, message 20 is received
- At time T1001, the retransmit task kicks in and asks the sender for retransmission of
messages [6-19]
- At time T1009, messages 6-19 are received
Problem: the out-of-order message 20 was received just before the retransmit task kicked
in. Has the task waited for another 9 ms (until time T1009), the retransmission would not
have been necessary.
The underlying cause is that the retransmit tasks handles recently added gaps the same as
gaps added before xmit_interval, as we don't maintain a timestamp for added messages.
Another reason is also that the message bundler on the sender side might send messages in
random order (see link below).
SOLUTION:
Investigate how to change the retransmission task such that it excludes gaps created
within the last xmit_interval ms.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: