[jboss-jira] [JBoss JIRA] Commented: (JGRP-1031) Asymmetric link down causes endless retransmission after merge
[
https://jira.jboss.org/jira/browse/JGRP-1031?page=com.atlassian.jira.plug...
]
Bela Ban commented on JGRP-1031:
--------------------------------
The issue is the following:
- The view after disabling 201 is:
201: 202, 201, 203
202: 202, 203
203: 202, 203
- Stability (STABLE) goes on between 202 and 203 (because they don't need to wait for
consensus from 201 as it's not part of their view)
- However, 201 does receive the stability messages sent by 203, and therefore removes
seqnos from 202, for example, although it never received them !
- When the merge happens, 201 now is missing messages from 202 and asks for retransmission
!!
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