[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:
--------------------------------
2 questions:
#1 Shouldn't GMS.fixDigests() solve the above issue (once a system is stuck) ?
(No, it doesn't because it only fetches digests from the current partition ! So,
not from 201)
#2 Should we maybe include 202 *and* 201 as merge coordinators ?
- This would entail making certain methods like handleMergeView() or
handleMergeRequest() executable also by participants
and not only by coordinators (CoordGmsImpl)
- What are the criteria for including members in the merge coords set ?
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