вт, 2 февр. 2021 г. в 11:05, Tom Talpey <tom@xxxxxxxxxx>: > > > Yes. If the server is tight on resources or just gives us less credits > > for other reasons (e.g. requests are coming out of order and the > > server delays granting more credits until it receives a missing mid) > > and we exhausted most available credits there may be situations when > > we try to send a compound request but we don't have enough credits. At > > this point the client needs to decide if it should wait for credits or > > fail a request. If at least one request is in flight there is a high > > probability that the server returns enough credits to satisfy the > > compound request (which are usually 3-4 credits long). So, we don't > > want to fail the request in this case. > > Ah, yes it's true that with no requests in flight, the wait would be > unbounded, and uncertain to gain credits even then. I think that is > well worth capturing in a code comment where the failure is returned. Make sense. Will add a comment and re-send the patch. > > It's still a concern that large requests may fall victim to being > locked out by small ones, in the low-credit case. A "scheduler", or > at least a credit reservation, would seem important in future. Or, > as mentioned, modifying the requests to consume fewer credits each. > > It's easy to envision a situation where a low-credit server can be > up, but a credit-greedy client might refuse to send it any requests > at all. > Agree. Falling back to sequentially sending compound components is needed to resolve such a situation. -- Best regards, Pavel Shilovsky
