Infinite queuing is almost always broken design so I agree with having a HWM and rejecting requests when the socket is not writable.
It would be nice to not have to reject requests simply because there are 0 handlers, though. This could be solved with a local queue (with maximum) to accumulate requests during the time when the socket is not writable. On Fri, Jul 3, 2015 at 12:24 PM, Henry Finucane <[email protected]> wrote: > Are you averse to adding a knob to re-enable the old behavior? I'm > sure someone somewhere is doing something goofy enough to rely on it- > although from your description it sounds maybe kinda sorta broken > anyway. > > On Fri, Jul 3, 2015 at 12:18 PM, Jason Miller <[email protected]> wrote: > > Hi All, > > > > Currently mongrel2 will queue up messages indefinitely to non-responsive > > handlers. This seems like not the behavior that people want. > > > > What are your thoughts on changing the behavior so that messages would > > be dropped when the channel is muted? > > > > The way this works with ZeroMQ is that if there are 0 handlers connected > to > > mongrel2, no messages will be queued. If there are N handlers connected > > to mongrel2 than "up to" N*HWM messages will be queued where HWM is > > configurable by us. The default value for HWM is 1000. > > > > The "up to" is in quotes since the ZeroMQ docs state that the HWM is not > > a guarantee and only 60-70% of the HWM may be achieved before muting in > > real-world scenarios. > > > > If nobody complains too loudly, I'll make this change on a feature > > branch, and hopefully others can try this and we can end up with a sane > > value for the default HWM. > > > > Regards, > > Jason > > > > > > -- > ----------------------- > | Henry Finucane > | "I hear aphorisms are popular" > ----------------------- >
