[
https://jira.jboss.org/jira/browse/JGRP-1031?page=com.atlassian.jira.plug...
]
Bela Ban commented on JGRP-1031:
--------------------------------
Investigate the following:
- 202 has #100, but 201 has only #50 from 202
- The new digest then shows #100 as highest seqno for 202
- However, will the MergeView sent by the merge leader (202) be queued by 201 because it
expects #51 from 202 ?
In other words, should we send the digests via unicasts to all merge participants ?
Is this the reason 201 doesn't receive the MergeView ?
Asymmetric link down causes endless retransmission after merge
--------------------------------------------------------------
Key: JGRP-1031
URL:
https://jira.jboss.org/jira/browse/JGRP-1031
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
Attachments: udp.xml
This is with FD only (don't use FD_ALL and remove FD_SOCK). The config is attached to
this case. We need to add <DISCARD use_gui="true"/> above UDP.
How to reproduce:
- Start 3 Draws:
draw -props ./udp.xml -name 202
draw -props ./udp.xml -name 201
draw -props ./udp.xml -name 203
- On 201: discard all traffic from 202
- Wait until the following views have been installed:
202: 202,203
201: 202,201,203
203: 202,203
Then enable reception of traffic on 201 from 202 again.
Then draw in all 3 instances. Looking at NAKACK, we'll see that the retransmission
table's size increases. We'll also see retransmission requests from 201 to 202
(for messages which seem to be in 202's sent-table !)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira