Ken,
On 4/14/15 1:36 AM, Ken McDonell 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.
OK, thanks for digging deeper into this.
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.
Yes, I had figured as much. From my perspective, it would be desirable
for pmLookupName give back correct information on valid metrics even if
the input list contains some bogus names.
Also, the python (and maybe perl, haven't checked) bindings will be
affected by any changes here. This was all triggered by my use of the
python bindings where the python implementation of pmLookupName does
different things depending on the status returned.
More details when I know how deep and smelly the bog is.
Thanks for bringing this up ... 8^)>
You're welcome? :)
Martins
|