followup: we should reserve some read handlers for reads.

[yunhanw-google]

This makes sense for a subscribe, but should a regular read just return Busy? Or is it that too many subscriptions can keep reads from working? If so, followup: we should reserve some read handlers for reads.

Originally posted by @bzbarsky-apple in #11667 (comment)

[bzbarsky-apple]

@mrjerryjohns @tcarmelveilleux This seems pretty critical to do: persistent subscriptions should not be able to completely lock out reads, which right now they can.

@franck-apple Do we have a label or project of some sort tracking "must happen for 1.0 to have sanity" work that is not really part of a bigger project? I guess I'll toss in "spec" for now....

[mrjerryjohns]

Yes, agreed. I'd recommend we reserve no more than 2 handlers (preferably, 1), since reads are not long-lived exchanges, and the chances of coincidental reads from multiple peers simultaneously is low.

Cases where that might not be true based on past experience would be a highly correlated event that affects multiple clients in the system simultaneously (like resumption from a comms outage, or power outage). I'm not certain we should over-design for that scenario anyways, since recovery from those usually takes time, and clients would have to be built to be defensive towards those cases anyways.

[bzbarsky-apple]

Yes, the reservation should be pretty small. Read attempts that run into no handlers get a BUSY status and can try again...