pcp
[Top] [All Lists]

Re: [pcp] pmLookupName sts differences

To: pcp@xxxxxxxxxxx
Subject: Re: [pcp] pmLookupName sts differences
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Tue, 14 Apr 2015 15:36:41 +1000
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <551D8119.5010404@xxxxxxxxxxx>
References: <551D8119.5010404@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
On 03/04/15 04:49, Martins Innus wrote:
Hi,
     Please see the attached code for an example of differences in
return value for pmLookupName when a metric is not found depending on
whether the top level namespace is handled by a dynamic pmda. For a
regular metric (non dynamic)  if we give it a bogus metric name, the
function returns fine, the appropriate pmID is set to NULL and "sts"
reflects the valid number of names converted, as expected.

Martins,

The pmLookupName API is broken for error cases in more ways than just dynamic metrics.

1. the man page is ambiguous
2. the code in libpcp and pmcd is not consistent, e.g.

pmLookupName -> -12357: Unknown metric name
[0] bad.metric.name PM_ID_NULL

pmLookupName -> 2
[0] sampledso.long.one 30.0.10
[1] sampledso.no.such.name PM_ID_NULL
[2] sampledso.long.ten 30.0.11
[3] bad.metric.name PM_ID_NULL

3. the function is executed in 4 different contexts (local PMNS, PM_CONTEXT_LOCAL, PM_CONTEXT_HOST and PM_CONTEXT_ARCHIVE) and the error cases are not handled the same in all contexts.

4. a metric name may fail to be looked up for a myriad of reasons.

Sigh.

I have a growing qa test (909) that is mapping out the places where this appears to be broken, then (after the next release is done) I'll start making code changes ... this will change the semantics of the ABI so I am very nervous about which path to take.

More details when I know how deep and smelly the bog is.

Thanks for bringing this up ... 8^)>

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