pcp
[Top] [All Lists]

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

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>, Nathan Scott <nathans@xxxxxxxxxx>, PCP <pcp@xxxxxxxxxxx>
Subject: Re: [pcp] pmcd gives up on slow starting Perl PMDA
From: Martins Innus <minnus@xxxxxxxxxxx>
Date: Mon, 24 Mar 2014 09:25:22 -0400
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <53300840.1070009@xxxxxxxxxxxxxxxx>
References: <532C975F.4020808@xxxxxxxxxxx> <532F56BC.9040500@xxxxxxxxxxxxxxxx> <146115274.4201680.1395623527453.JavaMail.zimbra@xxxxxxxxxx> <53300840.1070009@xxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
On 3/24/14 6:26 AM, Ken McDonell wrote:
On 24/03/14 12:12, Nathan Scott wrote:
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?

If I can get the BUSY case to work, then I think we can generalize the pmdaControl method to provide the sort of semantics you're after here.

We have proc pmdas that are timing out on heavily loaded systems, my next task was going to be looking into this. Should I wait until this new api/method is fleshed out before doing so?

Thanks

Martins

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