On 10/6/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 06.10.2006, at 23:12, Stephen Deasey wrote:
> On 10/4/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>>
>> On 03.10.2006, at 01:01, Stephen Deasey wrote:
>>>
>>>
>>> I was also wondering about the ns_proxy send/wait/receive. Why are
>>> wait and receive separate commands?
>>
>> Because you can wait, get the timeout, do something and then go
>> repeat
>> waiting. It makes sense. You can't achieve this with a longer wait
>> timeout OR with a timed [ns_proxy eval].
>> Allright, you can argue: one can [ns_proxy receive proxy ?timeout?]
>> in which case you have the same behaviour. Correct. But what
>> difference
>> would it make, really?
>
>
> Two commands make it twice as hard to use. All that's needed is a
> timeout switch:
>
> set result [ns_proxy wait -timeout 10 $handle]
>
Either way is OK. send/wait/recv is straight foward
and simpler if you usually HAVE to wait, whereas
send/wait_with_receive is more optimal if you mainly
don't need to wait (i.e. you tolerate indefinite block).
Don't forget: options are OPTIONS. Options should be
used optionally not regularily. Or?
I would say the -timeout option would rarely be given. The situation
will be similar to the cache command: in the common case a user
calling the command will have the timeout set by the connection's
timeout limit; for other callers, scheduled threads and so on, the
default timeout for the pool will be used.
If the timeout gets embedded at the call site it makes it difficult to
admin the system as a whole.
>
> The caller has a time budget. That's the total amount of time they're
> prepared to wait for a result.
Yes. This is the -evaltimeout limit.
But the call may take longer than the caller budgeted for, due to all
the hidden timeouts, which are additive.
So the callers time budget is 5 seconds, and that's what they pass to
-evaltimeout. But by default both the sendtimeout and recvtimeout are
5 seconds. So the total time spent on a successful call to ns_proxy
eval could be over 15 seconds, which is 3x the time budget.
The time budget is a single target value. In the future, for the
majority of users, this is going to be set per URL. For /checkout you
may allow up to 60 seconds to serve the page before deciding you're
overloaded. For /ads you may give up much sooner. Your server is busy
and you need to shed load, so you shed the least important traffic.
For a single page with some time budget, which depends on the URL,
some of it may be used up in a call to ns_cache_eval before there is a
change to call ns_proxy eval. i.e. the time budget is pretty dynamic.
I don't see how the multiple fine-grained settings of ns_proxy can be
used effectively in the simple case of a web page with a time budget
which runs multiple commands with timeouts.
> It's not free though. You get the odd effect of failing with a timeout
> when there's plenty of time left in the budget.
Right! Because part of the communication link might be severed.
Although your budged allows you to wait more, what good would that
be? See the above example.
Isn't a severed link a detectable error condition? The reaper will be
notified of the child death, or a hypothetical socket implementation
will have it's socket closed..?
> The error handling is also weird. As it's currently implemented,
> there's a different error code for each kind of timeout failure.
This way the programmer knows EXACTLY what happened.
Right.
But what is the programmer going to differently when he gets a ESend
vs. ERecv vs. EEval? Log it and continue. Maybe I'm not being
imaginative enough...?
I'm not saying you absolutely can't pass this back -- the error code
could be the Tcl list {NS_TIMEOUT ESend}. I just can't see the use of
it.
Better not to bug the programmer, log the fault for statistical
analysis, and move on.
Or, how about this. If it's agreed that these are fine tunings, could
they perhaps default to -1, and in that case the single timeout (which
is currently the eval timeout?) is used for everything until it runs
out?
