[
https://issues.jboss.org/browse/JGRP-1548?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1548:
--------------------------------
Hmm, the suggested solution is useless: *message batching* (bundling) gets in our way !
When A sends message 1-5 to B, then batching might send them as 1 batch. On B, we receive
a list of 5 messages and pass them up, *one by one* !
This means that we'd get A1, send an ack, A2, send an ack etc, so this is useless.
We have to look into passing the entire message batch up, adding them to the message
window first, and then process the messages. This way, we'd get a batch of 5 messages.
This solution requires a new event type (MSG_BATCH) though, which has to be handled by
some protocols (all below UNICAST2). Message batches would also have to be implemented by
UNICAST, NAKACK and NAKACK2.
I've looked at message batching before, but didn't implement it (forgot why
though...)
The other (simpler) solution would be for the thread that receives the message batch to
pass each message to a thread pool to be passed up, instead of passing them up
individually. I looked at this a couple of years ago, but the performance wasn't good,
possibly due to a high thread context switching rate.
UNICAST2: send STABLE message after 'last received' message
-----------------------------------------------------------
Key: JGRP-1548
URL:
https://issues.jboss.org/browse/JGRP-1548
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
Contrary to UNICAST, which acks every message, UNICAST2 never acks messages, but only
asks the sender to retransmit a message when a gap has been detected.
However, the drawback of this (negative ack) mechanism is the so called
last-message-dropped problem: when A sends messages [1..5] to B, but 5 is dropped by the
transport, as A doesn't retransmit messages until it gets a retransmission request
from B, B only gets messages [1..4].
B will *not* ask A to retransmit message 5, as B doesn't know A *sent* message 5 in
the first place.
If A doesn't send message 6 for B to detect 5 is missing and asking A for
retransmission, B won't get that message.
The way this is currently handled is with stable messages. A STABLE message is sent from
B to A every stable_interval ms or whenever M bytes from A have been received. In the
worst case, B will have to wait stable_interval ms until it finally receives message 5
from A.
SOLUTION:
In addition to time and size based STABLE messages, we could send a STABLE message
whenever the batch of messages removed from the receive window has completed and the
receive window is empty.
This would send a STABLE message immediately when a single message has been received (and
no other messages from A are in the receive window), but it would send another STABLE
message only when all (e.g.) 200 messages from A have been processed and the receive
window is empty.
With this new mechanism, we could even remove the time-based STABLE messages !
Example:
- At time T0, messages M1 and M2 are received. A STABLE message for M2 is sent.
- At T+500 (ms), messages M3-M100 are received. A STABLE message for M100 is sent
- At T+1500, M101 is received. A STABLE message for M101 is sent.
- At T+2000, M102 is received. A STABLE message for M102 is sent.
- At T+2010, M103-M500 are received. A STABLE message for M500 is sent
(Note that the example above didn't take size-based STABLE messages into account)
This is similar to the ACK based scheme in UNICAST where we only send an ack for the last
message in a batch (or for a single message if not batch has been received).
This new mechanism needs to be configurable: if enabled, the time-based STABLE mechanism
would be disabled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira