On Jun 2, 2010, at 2:25 AM, Hans Hübner wrote:
On Tue, Jun 1, 2010 at 17:04, Daniel Weinreb dlw@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@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel