2:35 a.m.
NAKACK: don't send retransmission requests individually
-------------------------------------------------------
Key: JGRP-1099
URL: https://jira.jboss.org/jira/browse/JGRP-1099
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.9
Currently, when we have messages 1,2 from P and receive 11, then we
- Add message 11 to the NakReceiverWindow
- This causes messages 3-10 to be added to the Retransmitter
These messages are added *individually*, so we have 7 new tasks in the Retransmitter. This
also means we send 7 retransmission requests rather than 1 !
Because retransmission requests are sent as OOB messages, they won't get bundled (see
[1]) ! Same for the retransmission responses (for OOB messages); they won't get
bundled.
Disadvantages:
#1 We send 7 retransmission messages rather than 1. This could be mitigated if OOB
messages were bundled though...
#2 We have 7 rather than 1 additional tasks in the Retransmitter. This taxes the
DelayQueue [2] used by the
ScheduledThreadPoolExecutor used by the Retransmitter
SOLUTION: go back to the old scheme of having tasks in the Retransmitter which have ranges
of seqnos rather than individual seqnos. This is a bit trickier though than single seqnos,
as a range of [3 - 10] needs to be broken into [3-5] and [7-10] if seqno 6 is received.
[1] https://jira.jboss.org/jira/browse/JGRP-1090
[2] https://jira.jboss.org/jira/browse/JGRP-1051
--
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:17 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1099) NAKACK: don't send retransmission requests individually
[
https://jira.jboss.org/jira/browse/JGRP-1099?page=com.atlassian.jira.plug...
]
Bela Ban commented on JGRP-1099:
--------------------------------
A range could be implemented via a BitSet and a low and high. For example, when the range
is 3-20, we create a BitSet of 18 (by default 1 long is allocated, which is 64 bits). When
we receive a message in that range, we set the corresponding bit, e.g. seqno #10 would set
bit 13 in the set (10 + offset of 3).
To get the ranges for retransmisson, we could run the following code below (method
printRanges()):
public static void main(String[] args) throws IOException, ChannelException {
BitSet set=new BitSet(20);
set.flip(0);
set.flip(3);
set.flip(8); set.flip(9); set.flip(10);
set.flip(15);
set.flip(130);
System.out.println("set = " + set);
printRanges(set, 20);
}
private static void printRanges(BitSet set, int capacity) {
int index=0;
int start_range=0, end_range=0;
while(index < capacity) {
start_range=set.nextClearBit(index);
if(start_range < 0)
break;
end_range=set.nextSetBit(start_range);
if(end_range < 0) {
System.out.println("[" + start_range + " - " +
capacity + "]");
break;
}
System.out.println("[" + start_range + " - " +
(end_range-1) + "]");
index=end_range;
}
}
NAKACK: don't send retransmission requests individually
-------------------------------------------------------
Key: JGRP-1099
URL: https://jira.jboss.org/jira/browse/JGRP-1099
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.9
Currently, when we have messages 1,2 from P and receive 11, then we
- Add message 11 to the NakReceiverWindow
- This causes messages 3-10 to be added to the Retransmitter
These messages are added *individually*, so we have 7 new tasks in the Retransmitter.
This also means we send 7 retransmission requests rather than 1 !
Because retransmission requests are sent as OOB messages, they won't get bundled (see
[1]) ! Same for the retransmission responses (for OOB messages); they won't get
bundled.
Disadvantages:
#1 We send 7 retransmission messages rather than 1. This could be mitigated if OOB
messages were bundled though...
#2 We have 7 rather than 1 additional tasks in the Retransmitter. This taxes the
DelayQueue [2] used by the
ScheduledThreadPoolExecutor used by the Retransmitter
SOLUTION: go back to the old scheme of having tasks in the Retransmitter which have
ranges of seqnos rather than individual seqnos. This is a bit trickier though than single
seqnos, as a range of [3 - 10] needs to be broken into [3-5] and [7-10] if seqno 6 is
received.
[1] https://jira.jboss.org/jira/browse/JGRP-1090
[2] https://jira.jboss.org/jira/browse/JGRP-1051
--
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
6:38 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-1099) NAKACK: don't send retransmission requests individually
[
https://jira.jboss.org/jira/browse/JGRP-1099?page=com.atlassian.jira.plug...
]
Bela Ban updated JGRP-1099:
---------------------------
Attachment: bla5.java
bla5 shows how MyRange can be used together with a sorted set to maintain a list of
MyRanges.
The (commented) use of BitSet shows how to handle one range, ie. this code would be added
to MyRange.
When the Retransmitter adds a new range, it would create a MyRange with a BitSet of (e.g.)
LOW to HIGH, and add it to the sorted set.
When a message is received, first the MyRange is looked up through the ceiling()
operation, then the bit in the BitSet is set.
For retransmission, the timer task calls a method similar to printRanges() which
determines the ranges and then calls retransmit(low, high) for each range.
When the BitSet is completed set (all '1's), then we cancel the task and remove
the MyRange from the sorted set.
NAKACK: don't send retransmission requests individually
-------------------------------------------------------
Key: JGRP-1099
URL: https://jira.jboss.org/jira/browse/JGRP-1099
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.9
Attachments: bla5.java
Currently, when we have messages 1,2 from P and receive 11, then we
- Add message 11 to the NakReceiverWindow
- This causes messages 3-10 to be added to the Retransmitter
These messages are added *individually*, so we have 7 new tasks in the Retransmitter.
This also means we send 7 retransmission requests rather than 1 !
Because retransmission requests are sent as OOB messages, they won't get bundled (see
[1]) ! Same for the retransmission responses (for OOB messages); they won't get
bundled.
Disadvantages:
#1 We send 7 retransmission messages rather than 1. This could be mitigated if OOB
messages were bundled though...
#2 We have 7 rather than 1 additional tasks in the Retransmitter. This taxes the
DelayQueue [2] used by the
ScheduledThreadPoolExecutor used by the Retransmitter
SOLUTION: go back to the old scheme of having tasks in the Retransmitter which have
ranges of seqnos rather than individual seqnos. This is a bit trickier though than single
seqnos, as a range of [3 - 10] needs to be broken into [3-5] and [7-10] if seqno 6 is
received.
[1] https://jira.jboss.org/jira/browse/JGRP-1090
[2] https://jira.jboss.org/jira/browse/JGRP-1051
--
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
9:40 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1099) NAKACK: don't send retransmission requests individually
[
https://jira.jboss.org/jira/browse/JGRP-1099?page=com.atlassian.jira.plug...
]
Bela Ban commented on JGRP-1099:
--------------------------------
For cases where the range is 1, we should create an instance of a different class, e.g.
Seqno handles single-seqno requests, whereas SeqnoRange handles real ranges.
We probable need to implement (and pass to the sorted hashmap) a Comparator<Seqno>
which compares Seqnos, SeqnoRanges and dummy Seqnos (Seqno.dummy set).
NAKACK: don't send retransmission requests individually
-------------------------------------------------------
Key: JGRP-1099
URL: https://jira.jboss.org/jira/browse/JGRP-1099
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.9
Attachments: bla5.java
Currently, when we have messages 1,2 from P and receive 11, then we
- Add message 11 to the NakReceiverWindow
- This causes messages 3-10 to be added to the Retransmitter
These messages are added *individually*, so we have 7 new tasks in the Retransmitter.
This also means we send 7 retransmission requests rather than 1 !
Because retransmission requests are sent as OOB messages, they won't get bundled (see
[1]) ! Same for the retransmission responses (for OOB messages); they won't get
bundled.
Disadvantages:
#1 We send 7 retransmission messages rather than 1. This could be mitigated if OOB
messages were bundled though...
#2 We have 7 rather than 1 additional tasks in the Retransmitter. This taxes the
DelayQueue [2] used by the
ScheduledThreadPoolExecutor used by the Retransmitter
SOLUTION: go back to the old scheme of having tasks in the Retransmitter which have
ranges of seqnos rather than individual seqnos. This is a bit trickier though than single
seqnos, as a range of [3 - 10] needs to be broken into [3-5] and [7-10] if seqno 6 is
received.
[1] https://jira.jboss.org/jira/browse/JGRP-1090
[2] https://jira.jboss.org/jira/browse/JGRP-1051
--
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
9:35 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-1099) NAKACK: don't send retransmission requests individually
[
https://jira.jboss.org/jira/browse/JGRP-1099?page=com.atlassian.jira.plug...
]
Bela Ban updated JGRP-1099:
---------------------------
Fix Version/s: 2.8
(was: 2.9)
NAKACK: don't send retransmission requests individually
-------------------------------------------------------
Key: JGRP-1099
URL: https://jira.jboss.org/jira/browse/JGRP-1099
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
Attachments: bla5.java
Currently, when we have messages 1,2 from P and receive 11, then we
- Add message 11 to the NakReceiverWindow
- This causes messages 3-10 to be added to the Retransmitter
These messages are added *individually*, so we have 7 new tasks in the Retransmitter.
This also means we send 7 retransmission requests rather than 1 !
Because retransmission requests are sent as OOB messages, they won't get bundled (see
[1]) ! Same for the retransmission responses (for OOB messages); they won't get
bundled.
Disadvantages:
#1 We send 7 retransmission messages rather than 1. This could be mitigated if OOB
messages were bundled though...
#2 We have 7 rather than 1 additional tasks in the Retransmitter. This taxes the
DelayQueue [2] used by the
ScheduledThreadPoolExecutor used by the Retransmitter
SOLUTION: go back to the old scheme of having tasks in the Retransmitter which have
ranges of seqnos rather than individual seqnos. This is a bit trickier though than single
seqnos, as a range of [3 - 10] needs to be broken into [3-5] and [7-10] if seqno 6 is
received.
[1] https://jira.jboss.org/jira/browse/JGRP-1090
[2] https://jira.jboss.org/jira/browse/JGRP-1051
--
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
9:40 a.m.
New subject: [JBoss JIRA] Resolved: (JGRP-1099) NAKACK: don't send retransmission requests individually
[
https://jira.jboss.org/jira/browse/JGRP-1099?page=com.atlassian.jira.plug...
]
Bela Ban resolved JGRP-1099.
----------------------------
Resolution: Done
Implemented using Seqnos and SeqnoRanges and a SeqnoComparator.
NAKACK: don't send retransmission requests individually
-------------------------------------------------------
Key: JGRP-1099
URL: https://jira.jboss.org/jira/browse/JGRP-1099
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
Attachments: bla5.java
Currently, when we have messages 1,2 from P and receive 11, then we
- Add message 11 to the NakReceiverWindow
- This causes messages 3-10 to be added to the Retransmitter
These messages are added *individually*, so we have 7 new tasks in the Retransmitter.
This also means we send 7 retransmission requests rather than 1 !
Because retransmission requests are sent as OOB messages, they won't get bundled (see
[1]) ! Same for the retransmission responses (for OOB messages); they won't get
bundled.
Disadvantages:
#1 We send 7 retransmission messages rather than 1. This could be mitigated if OOB
messages were bundled though...
#2 We have 7 rather than 1 additional tasks in the Retransmitter. This taxes the
DelayQueue [2] used by the
ScheduledThreadPoolExecutor used by the Retransmitter
SOLUTION: go back to the old scheme of having tasks in the Retransmitter which have
ranges of seqnos rather than individual seqnos. This is a bit trickier though than single
seqnos, as a range of [3 - 10] needs to be broken into [3-5] and [7-10] if seqno 6 is
received.
[1] https://jira.jboss.org/jira/browse/JGRP-1090
[2] https://jira.jboss.org/jira/browse/JGRP-1051
--
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
6016
days inactive
6033
days old
5 comments
1 participants
participants (1)
-
Bela Ban (JIRA)