10:35 a.m.
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
10:39 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-952) MERGE: UNICAST can lose messages on merging
[
https://jira.jboss.org/jira/browse/JGRP-952?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-952:
-------------------------------
Another solution proposed by Vladimir:
- Never trash a connection window on a view change
- Use an age-out cache with all connections
- On a view change, remove (but don't close !) all connections to *members* from the
cache
- The cache now only has connections to *non-members*
- When a cache element is older than N seconds, trash that connection from the connection
table and remove the element from the cache
==> A lot of connections could pile up until they're trashed. Basically a function
of N though...
==> Retransmission of messages to members in different partitions continues until the
partition heals
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
10:46 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-952) MERGE: UNICAST can lose messages on merging
[
https://jira.jboss.org/jira/browse/JGRP-952?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-952:
-------------------------------
The issue with Vladimir's solution is that a connection can still be closed by the
age-out cache, in that case we need to be able to handle asymmetric closings of a
connection anyway.
If the age-out time is set to a very high value, asymmetric closings will be very seldom,
but then unnecessary retransmission to members not in our view might go on for a long
time...
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
11:08 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-952) MERGE: UNICAST can lose messages on merging
[
https://jira.jboss.org/jira/browse/JGRP-952?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-952:
-------------------------------
OTOH, we can lose messages with NAKACK on a merge too:
- {A,B,C}
- A's seqnos for C is 5:10 (low:high delivered)
- Now there's a partition which has A: {A,B,C} and B,C: {B,C}
- B and C cannot talk to A
- C multicasts 20 new messages, so its digest for itself is 5:30
- Now STABLE adjusts that value to 20:30
- Now the partition heals
- A's digest for C is 5:10, but this will get overwritten by 20:30
==> A loses messages 10-20 from C
==> I guess this is okay, as a merge should always be succeeded with a state merging
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
11:37 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-952) MERGE: UNICAST can lose messages on merging
[
https://jira.jboss.org/jira/browse/JGRP-952?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-952:
-------------------------------
Alternative to first solution:
- When a message is received and cannot be *delivered* (e.g. #5 is received but we
haven't received #4 yet), then DO NOT ack it ! This means, A will keep retransmitting
#4 and #5, and retransmission will only stop for #4 when it has been delivered at B, and
the same for #5.
- This effectively acks a message only on remove(), not add() !
- In the above case, when A: {A,B,C} and B,C: {B,C}, then A would continue retransmitting
messages #4 and #5 to C until either a view was installed which excluded C, or a merge !
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
12:04 p.m.
New subject: [JBoss JIRA] Commented: (JGRP-952) MERGE: UNICAST can lose messages on merging
[
https://jira.jboss.org/jira/browse/JGRP-952?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-952:
-------------------------------
Addition to last comment: if we lose an ack, we have to make sure to ack subsequent
messages, e.g. as follows:
- A send #4 and #5 to B
- #4 is dropped
- B receives #5, adds it to its receiver window and doesn't ack it
- B receives #4, adds it to the receiver window for A
- B removes #4 acks it to A
- This ack is lost !
- B receives #4 again as a result of A retransmitting it
--> Because #4 has already been removed from A's receiver window at B, we'd
never ack it and A would continue resending #4 !
==> SOLUTION: when a message is received, ack it only if its seqno is lower than the
next seqno to be removed from B's receiver window at A. Otherwise, ack only on
remove() !
So in the example above, the spurious retransmission of #4 would get acked because
AckReceiverWindow.remove() set the next seqno to be removed to #5
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
8:40 p.m.
New subject: [JBoss JIRA] Commented: (JGRP-952) MERGE: UNICAST can lose messages on merging
[
https://jira.jboss.org/jira/browse/JGRP-952?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-952:
-------------------------------
Yet another alternative:
- We stick with the current alternative and ack messages as soon as they've been
received
- When we get a SEND_FIRST_SEQNO and we have gaps in the sender window, we trash the
sender window and send seqno #1
- This solution is in line with the first comment on this case
Example:
- 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
- A (re-)sends #4 to B
- B sends a SEND_FIRST_SEQNO to A
- A checks its sender window: it has #4 for retransmission, but the next seqno to be sent
is #6, so there is a gap
- A trashes its connection window, *but does not send anything* ! The next seqno to be
sent is #1 (with a conn-id because of the first seqno)
--> We could have copied the old #4 into the new sender window and sent it as #1. The
problem though is that we now send the old #4 but not the old #5; I think it's better
to trash them both !
--> This is in line with what we do in *non-overlapping* partitions: when we have #4 in
the sender window and there is a partition A:{A} and B:{B}, then both A and B trash their
connection windows and therefore lose both #4 and #5
--> As discussed in the above comments, this is also in line with NAKACK, which can
also lose messages on a merge
--> After a merge, all sub-partitions are supposed to fetch state anyway, or at least
merge their possibly divergent states
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
10:22 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-952) MERGE: UNICAST can lose messages on merging
[
https://jira.jboss.org/jira/browse/JGRP-952?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-952:
-------------------------------
If we stick with trashing the sender window on SEND_FIRST_SEQNO, we might actually trash
it multiple times !
- A sends #25 #26 #27 #28 #29 #30 to B
- B doesn't have a receiver window for B, so it sends 6 SEND_FIRST_SEQNO messages to
A
- On reception of the first SEND_FIRST_SEQNO, A trashes its window and sends #1 #2 #3 #4
to B
- B acks #3
- A's sender window is now #1 #2 #4 (#3 was acked)
- A receives the next SEND_FIRST_SEQNO message from B
- Because there are gaps in its sender window, it trashes its connection again !
A better solution:
- Have A send the conn_id with a SEND_FIRST_SEQNO message
- On reception of SEND_FIRST_SEQNO, we compare the conn_id sent with the message with our
send_conn_id. If they are the same, we trash the window *unconditionally*, else we send
the first seqno again
- Issue: we might have to send conn_id with *each message* !
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
10:59 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-952) MERGE: UNICAST can lose messages on merging
[
https://jira.jboss.org/jira/browse/JGRP-952?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-952:
-------------------------------
Wow ! Biggest argument AGAINST acking at delivery: acks might get lost ! Although later
resent when the same seqno is received, we might still end up with *gaps* in the sender
window (as described in the comment above) !
This is a showstopper for delivery-based acking and leaves us with the solution sketched
out above ("a better solution") !
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
11:07 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-952) MERGE: UNICAST can lose messages on merging
[
https://jira.jboss.org/jira/browse/JGRP-952?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-952:
-------------------------------
Looks like we need to ship the conn-id with each UnicastHeader. But since the conn_id
needs to be unique between 2 endpoints, we might be able to use just a byte (or short)
that we increment on each trashing and recreation of a connection !
Thanks to Vladimir for this suggestion !
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
11:19 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-952) MERGE: UNICAST can lose messages on merging
[
https://jira.jboss.org/jira/browse/JGRP-952?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-952:
-------------------------------
Actually, the previous but 1 comment is incorrect: when acks are sent on *delivery* (not
*reception*), then for an ack N we can ack all pending seqnos <= N !
If we get ack(5) --> ack(3) --> ack(4), then ack(5) acks *all* messages up to #5.
The other acks for #3 and #4 are simply discarded, because those message have already been
removed from the sender window !
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
11:27 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-952) MERGE: UNICAST can lose messages on merging
[
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
7:11 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-952) MERGE: UNICAST can lose messages on merging
[
https://jira.jboss.org/jira/browse/JGRP-952?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-952:
-------------------------------
Done on the 2.6.merge branch. Needs to get merged with the 2.6 branch, and forward-ported
to head
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
3:50 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-952) MERGE: UNICAST can lose messages on merging
[
https://jira.jboss.org/jira/browse/JGRP-952?page=com.atlassian.jira.plugi...
]
Bela Ban updated JGRP-952:
--------------------------
Fix Version/s: 2.6.10.merge
(was: 2.6.10)
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.merge, 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
5:33 a.m.
New subject: [JBoss JIRA] Resolved: (JGRP-952) MERGE: UNICAST can lose messages on merging
[
https://jira.jboss.org/jira/browse/JGRP-952?page=com.atlassian.jira.plugi...
]
Bela Ban resolved JGRP-952.
---------------------------
Resolution: Done
Forward ported from 2.6 to CVS head (2.8)
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.merge, 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
6306
days inactive
6326
days old
14 comments
1 participants
participants (1)
-
Bela Ban (JIRA)