Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Stephen D. <sd...@gm...>]

On 6/22/06, Zoran Vasiljevic <zv...@ar...> 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?