On Jun 5, 2010, at 4:26 AM, Hans Hübner wrote:
Scott,
just as a clarification: I think that if thread pools are not useful (which seems to be the case), we should not have stubs in there for them. I do think that your change, which allows limiting the number of client threads that Hunchentoot has active at any one time, should have the two discussed modes when the limit has been reached: The default mode would be to pause accepting requests or, once the queue runs full, to reject them. The alternative mode would be to accept all new connections but reply with a 503.
I don't know what the state of your patch is now, but I guess that the above is what you have implemented. This is just to verify that we're on the same page.
Yes, the above is what I have implemented. I'll remove the "pooled thread" stub on Monday (too busy this weekend).
Right now, the default for 'one-thread-per-request-taskmaster' (or whatever it's called) is what it used to be: just keep accepting connections. If you'd like me to change that to "accept N connections and spin off a thread; queue up a few more connections; then issue HTTP 503", that would suit me just fine. It seems like a good, default behavior. The one question I have is, what should N be and what should the increment be beyond which we reject? I'm thinking something like allow 8 threads, and 2-4 on the queue, but I'll go with whatever you think is reasonable.