On 6/22/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
Am 21.06.2006 um 19:01 schrieb Stephen Deasey: > Look at the aolserver head, at nsd/limits.c. A 'limits' is a > collection of setting such as max upload size, timeout etc. You > create one or more of these then bind them to a URL, just like > ns_register_proc. But Stepehn, lets look this from another perspective... We use NS to about 80-85% as a general purpose application server and to the rest as webserver. For us, binding a limit to an URL does not mean much. Instead we have divided our code in multiple C and Tcl modules we plug into the server and each module has its own configuration section where we draw defaults/limits etc, falling back to defaults built into the server. WFor example, we use -timoeut option for generating cache to be able to create a cache per-module with per-module defaults. This is of course different for every module. How are we to solve this with the scheme you are proposing or with the a'la AOLserver limits infrastructure (per URL based) ??? Can we "bind" those limits to whatever we want? How is this working in detail? Do you have a executive summary (in a nutshell) for me or do I have to go to AS sources and learn all that from there?
You chopped out the description from your quote above :-) The idea is to use the idea of 'limits', as aolserver does, but to use the timeout limit in a broader way. The aolserver timeout limit refers only to the amount of time connections spend waiting for conn threads before being dropped. The idea here is to extend that and say the timeout is the total amount of time the connection should spend running. A single page request can often have more than one call to ns_cache_, ns_httpget, ns_prcxy, ns_job, and so on. You can set the timeout for each call to ns_cache to be 30 seconds. If the first call completes immediately, but the second takes 31 seconds, your page fails. However, by definition you were quite prepared to wait 58 seconds for the page to complete. When a connection is accepted the time is logged. Depending on the URL, a particular limit is selected, say 30 seconds. This is added to the accept time to get a time in the future beyond which you're not prepared to wait on a condition variable used by any of the calls mentioned above. You mentioned modules with different timeout values. It depends how you use them. If your accessing a cache from a scheduled proc, then you don't have a URL to get a limit, so perhaps you want some per-cache settings. I guess you might insist that even with the URL limit available, one cache absolutely needs to wait significantly longer than another and you're prepared to accept the limitations mentioned above that happen when you add a series of timeouts together. Either way, per-cache timeouts seem reasonable. But this is a Tcl thing. There's a new Tcl cache structure for storing this info. Tcl and C are so different that it's just a limitation to force this into the C cache routines. Here's a question though: if you have URL limits and per cache limits, which takes precedence?
