[
https://jira.jboss.org/jira/browse/JGRP-952?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-952:
-------------------------------
This is the revival of the ack based scheme ! Because the following use case is a
disadvantage to the 'trash the sender window on SEND_GET_FIRST message' scheme:
- A has #25, B trashed its connection window
- After a partition heals, A becomes the merge leader and sends a unicast MERGE-REQ to B
- This is #26 and in A's sender window
- B sends a SEND_FIRST_SEQNO message to A
- A trashes its sender window and, along with it, its seqno #26 (the MERGE-REQ)
- Unless A copies all element from the old sender-win into the new one and assigns them
new seqnos, MERGE-REQ will not be received by B !
--> Copying existing elements of A's sender window might be dangerous: we could
have had #11 #13 #14 (#12 has already been ack'ed), and so the original #12 would
never be delivered at B !
MERGE: UNICAST can lose messages on merging
-------------------------------------------
Key: JGRP-952
URL:
https://jira.jboss.org/jira/browse/JGRP-952
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.6.10, 2.8
The following use case loses messages:
- A sends #5 to B
- B expects #4 from A, but adds #5 and acks it
- A receives the ack(#5) and removes #5 from its sender window
- Now there is a partition such that B trashes its connection window form A, but A keeps
its window for B (A: {A,B}, B: {B})
- The partition heals and A sends #6 to B
- B asks A for its lowest seqno, A resends #4 (with a conn_id)
- B creates a receiver window for A with seqno=#4
- A resends #6
- B adds #6 to its window, but doesn't deliver it because it is missing #5
--> However, A will NEVER resend #5 because the ack(#5) from B removed #5 from A's
sender window !
==> Possible SOLUTION: when A gets the SEND_FIRST_SEQNO and there are (unacked)
messages in A's sender window, and they are not in order, then A will trash its
connection window and copy the pending messages into the new window (with new seqnos !)
before sending #1 (with conn_id)
==> This solution might lose the original message #5, but that's better than B
never being able to deliver any messages anymore !
--
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