pcp
[Top] [All Lists]

Re: [pcp] pmcd gives up on slow starting Perl PMDA

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [pcp] pmcd gives up on slow starting Perl PMDA
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sun, 23 Mar 2014 21:12:07 -0400 (EDT)
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <532F56BC.9040500@xxxxxxxxxxxxxxxx>
References: <532C975F.4020808@xxxxxxxxxxx> <532F56BC.9040500@xxxxxxxxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: 6x6SRrg7EU45lh7E7gXFoNDF6WhzKw==
Thread-topic: pmcd gives up on slow starting Perl PMDA

----- Original Message -----
> [...]
> === PMDA has to have a big think after start up ===
> 
> At some point, one of the PMDA callback routines is called and
> the PMDA knows it need to do something to reconfigure itself or
> probe for something or ... anything that might take longer than
> the pmcd timeout.
> 
> The current request cannot be serviced before the long delay, so
> it will return PM_ERR_PMDANOTREADY to pmcd, then do what needs
> to be done, then return PM_ERR_PMDAREADY to pmcd.

Thinking more deeply on this, it occurs to me that one possible
problem here is that the PMDA doesn't necessarily know if it is
going to take a long time.  This proposed model, AIUI, would
require that whenever a PMDA *might* take a long time, it has
to tell pmcd, even if it doesn't end up taking a long time.

The potential problem there is that pmcd might get some client
request at an unfortunate time, which might have been quickly
satisfied by the PMDA, but could end up telling the client we
had a slow PMDA, when in fact we did not.  e.g. I'm thinking of
the pmdaproc case here, where a /proc scan may be quick, or it
may not.  It may be possible to tackle this using a thread in
libpcp_pmda which has a timer, and if the timer is not quickly
cancelled then the thread could inform pmcd of the delay as it
is happening?

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>