[hunchentoot-devel] 'max-threads' behavior for Hunchentoot
Scott McKay
swm at itasoftware.com
Thu Jun 3 19:12:50 UTC 2010
On Jun 2, 2010, at 2:25 AM, Hans Hübner wrote:
> On Tue, Jun 1, 2010 at 17:04, Daniel Weinreb <dlw at itasoftware.com> wrote:
>> I don't understand what race condition you mean.
>> Would you please explain?
>
> Rereading the patch, I withdraw my concern. The closing and opening
> of the socket happens when there is a problem anyway, so it is not too
> bad if one connection more or less gets dropped. But I think I have
> trouble understanding what the code really wants to do, a comment
> describing the intended behavior would be helpful.
>
>> About rejecting connections: We understand that
>> this behavior would not always be desirable,
>> and I assumed that Scott means it as an option
>> rather than the only possible behavior. This
>> behavior can be useful in a cluster of servers,
>> in which you'd like to tell the load balancer
>> that it should choose another server.
>
> There should be two configurable modes as to how Hunchentoot handles
> an incoming connection when no handler thread is available: One would
> set up things so that the connection is accepted, but a 503 error is
> sent out right away. The other would suspend accepting connections
> until a thread is available. The latter mode would make new clients
> hang (and, if the listener queue runs full, be rejected) until
> resources are available again.
>
The latter is a nice idea, but I have no good idea how to
implement it portably, given the very limited thread model
provided by Bordeaux Threads.
> Applications that use a load balancer with multiple backends would use
> the first mode in order to always get quick responses. Applications
> that consist of only one server would use the second mode with a
> suitable backlog configuration so that load peaks can (sometimes) be
> handled without rejecting client connections.
>
> -Hans
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
More information about the Tbnl-devel
mailing list