[jboss-jira] [JBoss JIRA] (JGRP-1548) UNICAST2: send STABLE message after 'last received' message

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746162#comment-12746162 ] 

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