[jboss-jira] [JBoss JIRA] Closed: (JGRP-479) Credits replenishments only return the bytes read *not* the full credits

[Bela Ban (JIRA)]

     [ http://jira.jboss.com/jira/browse/JGRP-479?page=all ]

Bela Ban closed JGRP-479.
-------------------------

    Resolution: Won't Fix

Not needed as we don't proactively send credits, as described in JGRP-481

> Credits replenishments only return the bytes read *not* the full credits 
> -------------------------------------------------------------------------
>
>                 Key: JGRP-479
>                 URL: http://jira.jboss.com/jira/browse/JGRP-479
>             Project: JGroups
>          Issue Type: Sub-task
>    Affects Versions: 2.4.1 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5
>
>
> Currently, a receiver always returns the full credits rather than the credits actually *received* by the receiver. Brian's description is below:
> FC does not control flow tightly enough. I believe this may be because credit replenishments bring a sender up to max_credits from *whatever credit level* the sender is at, which has no direct relationship to how many bytes the receiver had seen. This is more of a problem under sustained over load when sender threads are timing out while blocking and sending credit requests. For example, with a config of max_credits = 1,000,000 and min_credits = 100,000. Sender is under enough client load that it basically always has sender threads blocking with messages totalling 1,000,000 bytes.
> Sender sends 1,000,000 bytes and blocks.
> Receiver processes slowly.
> Receiver processes 900,000, sends credit replenishment 1.
> Meanwhile, sender times out; sends credit request 1.
> Sender gets credit replenishment 1; unblocks, sends another 1,000,000, blocks again.
> Receiver processes 100,000, then gets credit request 1 and sends replenishment 2.
> Sender times out; sends credit request 2.
> Sender gets replenishment 2 and unblocks, sends 1,000,000 bytes.
> At this point, the sender has sent 3,000,000 and the receiver has received 1,000,000. Further, there is a credit request in the channel, so after the receiver sees the next 1,000,000 bytes, it will have sent two more replenishments, theoretically allowing the sender to send 2,000,000 more bytes.
> This is an extreme example, but the key point is a credit replenishment gives the sender the right to send up to max_credits, even though the receiver may have only seen min_credits when it sent the message.
> Solution to this problem is two-fold:
> 1) Credit replenishment messages should include a payload indicating the number of bytes received. The sender only gives itself that many credits. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira