On Saturday 11 August 2007 19:34, Dossy Shiobara wrote: > On 2007.08.11, Tom Jackson <[EMAIL PROTECTED]> wrote: > > 1. The new default and error pools remain initialized as follows (same as > > before): > > minthreads 0 > > maxthreads 10 > > maxconns 0 > > timeout 120 > > > > Although I'm not sure why this is considered 'unlimited'. > > "maxconns" set to 0 means "unlimited." >
Maybe I don't understand maxconns, isn't this the number of connections to be served before the thread exits? Maxthreads? Seems to be limited to 10, so no more than 10 threads can exist at one time. > > 2. ns_pools is used to configure server specific pools, the API has not > > changed. However, the server name is prepended to the pool name supplied: > > > > 'ns_pools set fast' in server named 'jnm' creates a pool named > > 'jnm-fast'. > > > > This seems not good until you use ns_pools list: > > > > ns_pools list jnm-* > > jnm-default jnm-fast > > > > or: > > > > ns_pools list [ns_info server]-* > > jnm-default jnm-fast > > I really dislike this approach. What about adding "?-server > servername?" to the API: > > ns_pools list -server foo > default error > Yes, I postponed any work on this option for three reasons: 1. I didn't want to deal first with arg parsing. This requires a little more work on all the API, that is the API changes in every case, or some special case needs to be derived for the global default/error/other pools. 2. The name of the pool, used in the thread naming is now more difficult, maybe not too much. 3. Maybe the most important: the server name still has to be incorporated into the name to create a unique hash entry. None of this has eliminated the possibility of having global or process wide pools, but at the moment there is no enforcement of overall limits. That is, I can create another threadpool or limits based upon a url pattern and essentially override the global limits. Until this is done via some admin module, the same thing can be achieved on a per server basis. I guess what I am saying is that enforcing policy implies someone to enforce it against, which implies you have controls to enforce. These don't exist at present. So one option I was considering is to change the internal API a little so that a base procedure would take (pool, server), with the admin code using server=NULL. I'm not sure what you call this exactly, it is done a lot in the AOLserver code. > Also, what if you need a pool/limit that does is shared across all > servers in the entire process? This is actually the truly useful use > case of the pools/limits mechanism--e.g., ensuring that the entire nsd > process doesn't attempt to use more than X number of threads, whatever > that X is that the physical machine can support based on its > size/capacity. > I agree, I think we should consider an admin module which can enforce this, at the moment every server can add as many threads, etc as they wish. I'm not sure that it is good to have each server able to change setting for other servers, although this setup at least allows listing and getting and querying all pools. 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.
