On Wed, 05 May 2010 07:39:30 +1000, Ken McDonell wrote:
kenj> I'm suggesting that we remove all the asynchronous PMAPI extensions from
kenj> libpcp as part of a PCP 4.0 goal.
This is a provocation, nay, this is a casus belli, or maybe just a
Wednesday with its bugs.
kenj> 2. the routines are not used by pmchart
Which is probably a fault of pmchart, neh?
kenj> 3. the implementation is incomplete ... man pages exist for at least the
kenj> following but there is no code in libpcp to implement these functions:
kenj> pmRequestStore, pmRequestNamesOfChildren (oddly,
kenj> pmReceiveNamesOfChildren is in the library!), pmRequestNameAll,
kenj> pmReceiveStore and pmReceiveNameAll.
pmRequestNamesOfChildren is in the library too but misspelt slightly.
kenj> 4. the last time I raised this question, the only justification for
kenj> these routines was suggest by Max to be ... "when collecting metrics
kenj> from multiple hosts I cannot afford for TCP to pick its nose when one of
kenj> the hosts go down". But I can find no evidence of any application that
kenj> actually uses these routines to deal with the "one of many hosts may be
kenj> down" scenario, and indeed the cluster PMDA which might be a candidate
kenj> does not use the pmRequest*/pmReceive* family of routines.
Once again, maybe it says something about cluster pmda and how naive
its implementation is, although if we're talking about pmclusterd,
IIRC it was written using push model.
kenj> 5. there is zero QA coverage for the asynchronous routines (I was
kenj> recently doing some gcov analysis in pmns.c which brings this issue into
kenj> stark relief and triggered this mail).
pmns side was the most troublesome (worse then connection
establishment) to split into request/response parts, every other
synchronous API routine was re-written to use two parts of async
routines and as such should be well covered by PCP QA.
kenj> So unless someone can come up with a real use case and someone steps up
kenj> to help with the QA coverage of these routines I am strongly suggesting
kenj> that they be expunged at the next really major release, i.e. 4.0
As gnb said, we do have a process which uses async API in real life.
And mort should check withing SGI is nasmgr is still alive - it used
to use this API.
So, what's the real issue? Lack of QA coverage or code bloat?
max
|