[jboss-jira] [JBoss JIRA] (JGRP-1873) UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender

[ https://issues.jboss.org/browse/JGRP-1873?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1873: --------------------------- Description: In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table. Example: * A sends messages to B * A has an entry for B in its send-table: {{B: 10|20}} (low=10, highest sent=20) * B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20) * B now gets a view that doesn't contain A and closes its connection to A ** This results in B's connection to A getting removed * A now sends message {{A::21}} * B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A * A receives the request and sends message {{A::10 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that all of them are dropped. * B creates an entry for A in its recv-table: {{A: 10|21}} * Now a spurious {{STABLE(A::12)}} message by B is received by A ** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection ** Note that the connection ID ({{conn-id}} is the same, so the sender will not reject the {{STABLE}} message * A receives the {{STABLE}} message and purges elements lower than 10, so its new entry for B is: {{B:: 12|21}} * When B asks A for retransmission of messages {{A::10}} - {{A:21}}, A can only retransmit messages 12-21, but *not* {{A::10}} and {{A:11}} ! was: In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table. Example: * A send messages to B * A has an entry for B in its send-table: {{B: 10|20}} (low=10, highest sent=20) * B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20) * B now gets a view that doesn't contain A and closes its connection to A ** This results in B's connection to A getting removed * A now sends message {{A::21}} * B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A * A receives the request and sends message {{A::10 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that all of them are dropped. * B creates an entry for A in its recv-table: {{A: 10|21}} * Now a spurious {{STABLE(A::12)}} message by B is received by A ** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection ** Note that the connection ID ({{conn-id}} is the same, so the sender will not reject the {{STABLE}} message * A receives the {{STABLE}} message and purges elements lower than 10, so its new entry for B is: {{B:: 12|21}} * When B asks A for retransmission of messages {{A::10}} - {{A:21}}, A can only retransmit messages 12-21, but *not* {{A::10}} and {{A:11}} ! -- This message was sent by Atlassian JIRA (v6.3.1#6329)