Re: [naviserver-devel] nsproxy API

[Zoran V. <zv...@ar...>]

On 07.10.2006, at 00:39, Stephen Deasey wrote:

>
> But the call may take longer than the caller budgeted for, due to all
> the hidden timeouts, which are additive.
>

True.

> 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.

How would you handle this issue then?
Given you have 5 seconds budget to run the proxy command
and the fact that running the command involves round-trips
to some remote proxy on another host, how would you implement
that? You have to send the data to the proxy and then you need
to wait for all the data to come back. Would you break the
potentially valid request because it needs 5.01 secs to get the
last byte transfered back just because your total limit was set to
5 seconds?

If you can give a good solution, I will implement that immediately.


>
>
>>> 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..?

Not necessarily ( a detectable condition). If the remote proxy is
on other host and somebody cuts the wire, you get no error. You
need to timeout sometimes.

>
>
>>> 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...?

No, you are right. There is not much he can do except to log that
and move on. But the fact that he KNOWS what was the error he CAN
log better.

>
> 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.

YES. Actually who logs it is not that important, just the fact
that this should be logged is important. Seeing it from this
perspective, it is really better to give a "generic" timeout
and adjust statistics rather than expose _exact_ errorcode up to
the script level. I can agree with you on that point.

>
>
> 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?

Hmhmhm.... tempting... but would be a victim of:

   I waited 1 minute for 100-byte result, got 99 of 100 bytes
   and the timeout expired. I consider the request timeouted
   and break. But the peer would return the last byte in perhaps
   10 msec... Too bad.

Lets see what you thing about this.

But if we make this change, then we need no counters of errors at
various places because they will make no sense. Effectively
we have a budget of -evaltimeout which is divided across all
possible points where we will/must wait. A timeout expiring at
any of this point has no meaningfull information at all any more.
Right?


>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys -- and earn  
> cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel