[jboss-jira] [JBoss JIRA] Commented: (JGRP-1031) Asymmetric link down causes endless retransmission after merge

[Bela Ban (JIRA)]

    [ https://jira.jboss.org/jira/browse/JGRP-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12483352#action_12483352 ] 

Bela Ban commented on JGRP-1031:
--------------------------------

We have the following situation (members 201, 202 and 203) and their views:

[201]: [202|2] [202, 201, 201]
[202]: [202|3] [202, 201]
[201]: [202|3] [202, 201]

The different views are [202|2] and [202|3} and these are passed up the stack to GMS (by MERGE2).

The coordinator is 202 and it will multicast a MergeView to all members of the consolidated view. However, for the reasons outlined above, the multicast will not be received by 201 as its next seqno expected from 202 is lower than the actual seqno sent by 202. Therefore, 201 will queue the MergeView message up, but it will never receive the older messages from 202 because 202 and 203 had a stability event which purged older messages !
The MergView contains a digest, which would correct the situation, but 201 will never deliver the message, therefore not apply the digest !

Possible solution: in merges with a single coordinator, *unicast* the MergeViews ?

> 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