robey
commented
12 years ago i'm not sure i like this idea.
if the queue is filling up, the system is fundamentally overloaded, because the "steady state" of the system should be that there are at least as many consumers as producers, and the queue is empty. so if the system is overloaded, it's better to shed load quickly than to push the backpressure back up toward users.
kestrel offers a few ways to shed this load: you can limit the queue size, and set a policy of refusing new work or dropping old work (in other words, prioritize old work, or new work). you can also just use your disks as the release valve, let the queues back up for as long as your disk lasts, and hope things recover. if they don't, you can manually flush the queues and throw away a big chunk of work. (we actually used to do this. in a crisis, it's better than going offline.)
Additional feature that is similar to blocking get (i.e., get with timeout). I am thinking of a set/t=500 similar to get/t=500. That means, whenever you put a new item in the queue and the queue is already full, the client will be blocked for at most 500ms until an error occurs.