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

[Hans Hübner]

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.

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