On Friday 19 October 2007 03:17, Gustaf Neumann wrote: > The problem > actually happend when the number of available connection threads > is configured very low, as well as the the number of requests > per connection thread (e.g. 5 and 3). When the server accepts a > high number of requests, these are queued even without > guaranteeing resources to process these.
I know this is true, several months ago I configured a threadpool with zero threads after startup. The driver thread will still send requests to the threadpool queue, where it will sit forever. Also, if you then configure the threadpool with more threads after going to zero, they are never created. I also noticed that you should be able to trigger the driver by calling the Tcl command [ns_driver query ...], so maybe an experiment with a scheduled proc would be interesting: put the server into the unresponsive mode and see if it gets unstuck. The log should show the scheduled thread running, then hopefully the server unsticking. Otherwise it isn't necessarily the driver thread which is stuck, so triggering it would be pointless. I can try running my tests again with 3-5 threads, what other parameters were there? Does this get stuck running OpenACS on any machine, or just on openacs.org? Okay, just read Gustaf's comments on his patch, there might be a problem with the configuration on openacs.org, see below... > The situation > is especially bad with bursty requests. When a connection thread > exits e.g. after 3 requests, and there are still many requests queued, > there is no mechanism to automatically trigger new > connection threads in this situation. When a client connects > in this situation to the server, some old (maybe obsolete) requests > are taken from the queue, but after this, the server might sit idle > even with a high number of requests queued. As above, I wonder if the driver thread and the exiting connection thread should signal the queue thread? There seems to be something not complete with the queue loop. Also, Gustaf, the maxconnections should be higher...with maxconnections=3 you are exiting a connection thread every three requests, is this how you want it to work? If resources are limited, this isn't going to help. > > I have commited a patch to cvs head, that processes these pending > requests, even when maxconns is exceeded. Maybe it is better to > restart exiting connection threads automatically or to limit the > number of queued requests at first hand; or maybe there is a callback > solution. However. I have removed the old - useless - patch > from the head version in CVS. > Very interesting, I'll look into this more today. One thing I didn't try was a configuration where maxconnections was lower than the number of simultaneous requests from Apache Bench. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
