Re: Good guy timers

On 3/26/2014 10:46 AM, David Barbour wrote:
>
> On Wed, Mar 26, 2014 at 12:02 AM, Jed Donnelley 
> <capability-iCFHVraI1K1Wk0Htik3J/[email protected] <mailto:capability-iCFHVraI1K1Wk0Htik3J/[email protected]>> wrote:
>
>
>     The only reason timers (at least at the top level - there are some
>     other
>     issues at the bottom) are needed is to deal with resource issues.
>
>
> There are also "dead man's switch" issues (e.g. if controlling a robot 
> through a web page).

I'm not sure I understand the "dead man's switch" issue that you mention 
above.
However, regarding:

> And some kinds of resources might be problematic if kept around 
> without a consumer (e.g. server-side video acquisition and buffering 
> is expensive, and buffers quickly become more so if not consumed). 
> Depends on the problem domain.

It seems to me that such buffering would be suitable for a "good guy" timer
mechanism as such buffers would be available at need (unless requested
before a very short timeout), but held buffers would not be recycled before
they were needed.

>
>     We did have a "timeout" - that is a time after which we would consider
>     recycling such threads before their processing was complete.  However,
>     we only did so if they were needed for incoming requests.  The basic
>     idea was that we had a trigger value (minimum number of available
>     threads) below which we would look for threads to recycle.  We
>     wouldn't
>     consider any threads that hadn't yet reached their "timeout" value (in
>     that case if we ran out of threads we would block incoming
>     requests) and
>     we would recycle others on an oldest first basis.
>
>
> This is a nice approach, assuming relatively passive resources.

I'm not sure what you mean by "passive" in the above context.  The threads
that we recycled tended to be rather active unless stuck, constantly being
used for processing incoming requests.

> I've been contemplating a similar technique, albeit at the session 
> state layer (i.e. allowing old sessions to be resumed, but recycling 
> those more than a month old or so).

The key for us was to:

1.  Not simply throw away state and recycle resources based on a time 
expiring, but

2.  Only recycle such resources if a time had expired AND the resource 
was needed
(e.g. we were experiencing something like a DOS attack or some other 
high load
with low response clearing).

With such an approach we could also set the timeout value relatively tight
because it would almost never trigger abortion of a request whose processing
was delayed - since they were being "good guys" and only triggering at need.

>
>     friam/cap-talk
>
>
> I hadn't heard of the friam google group. I guess I'll need to check 
> it out.

--Jed

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk