[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