[hunchentoot-devel] 'max-threads' behavior for Hunchentoot

[Scott McKay]

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.