| 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 |
| Previous by Date: | Re: [pcp] pmcd gives up on slow starting Perl PMDA, Martins Innus |
|---|---|
| Next by Date: | Re: QA dev branch notes, Dave Brolley |
| Previous by Thread: | Re: [pcp] pmcd gives up on slow starting Perl PMDA, Ken McDonell |
| Next by Thread: | Re: [pcp] pmcd gives up on slow starting Perl PMDA, Ken McDonell |
| Indexes: | [Date] [Thread] [Top] [All Lists] |