[jboss-jira] [JBoss JIRA] (JGRP-2084) FlowControl: receiver should replenish credits after message delivery, not before

[Bela Ban (JIRA)]

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

Bela Ban edited comment on JGRP-2084 at 6/24/16 2:43 AM:
---------------------------------------------------------

Hmm, there's a problem: in the old approach, messages from P received at the same time would only set P's credits to max_credits *once*. With the proposed change, P's credits could be set to max_credits many times, defeating the purpose of flow control!
E.g. (max_credits=1000, min_credits=400, msg size=100, left credits=500):
* P1 (message 1 from P) decrements credits to 400: will increments credits for P by 600 and send 600 credits to P
* P2 decrements credits to 300: increment by 700 and send 700 credits
* P3 decrements credits to 200: increment by 800 and send 800 credits
* Now P1-3 are done delivering the message. They will now increment P's credits by 600, 700 and 800 (note that P's credits will never go over 1000), but they will also send credits worth 600, 700 and 800 bytes to P!

SOLUTION: revert to the old approach, which only sets credits for P to max_credits once, but send the REPLENISH message *before* delivering the message.



was (Author: belaban):
Hmm, there's a problem: in the old approach, 10 threads from P received at the same time would only set P's credits to max_credits *once*. With the proposed change, P's credits could be set to max 10 times, defeating the purpose of flow control!
E.g.:
* Thread 1 from P (P1) is received, decrements P credits and drops below min_credits. P1 is now delivered, while P's credits are below min_credits
* Thread P2, P3, P4 are received: they all decrement P's credits see that they need to set P's credits to max
* When P1-4 have delivered the message, they will all set P's credits to max_credits!

> FlowControl: receiver should replenish credits after message delivery, not before
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-2084
>                 URL: https://issues.jboss.org/browse/JGRP-2084
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.6.10, 4.0
>
>
> When a message from P of length LEN is received, the following algorithm is run:
> * P's credits are decremented by LEN
> * If this is less than min_credits:
> ** Set P's credits to max_credits
> ** Deliver the message
> ** Send a REPLENISH message back to P
> The problem here is that, if the deliver of the message blocks (e.g. because another sync RPC is invoked on the same thread), then other threads from P sending messages won't cause a REPLENISH message to be sent back to P.
> SOLUTION: replenish P's credits only _after the message delivery_:
> * P's credits are decremented by LEN
> * If this is less than min_credits:
> ** Deliver the message
> ** Set P's credits to max_credits
> ** Send a REPLENISH message back to P
> Email from Dan:
> {quote}
> ... when a message is received that passes over the min_credits threshold, the credits for that sender are already adjusted to max_credits - so only this thread can send a REPLENISH message back. If this thread blocks in the application (e.g. it sends a message and it blocks to wait for credits), even though other threads successfully deliver other messages, FlowControl will not send a REPLENISH message.
> So it only takes one delayed/dropped REPLENISH message to enter a vicious circle, where nodes keep not sending REPLENISH messages to each other. And credit requests can't really help here, because there are way too many concurrent requests, and credits are immediately exhausted.
> ...I think the best solution would be to have the receiver increment credits only *after* the application handles the message. I don't think the receiver needs to do anything before
> delivering the message, because the blocking happens on the sender side anyway.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)