On 24/03/14 12:02, Nathan Scott wrote:
...
In this case, there is a problem in that pmcd currently assumes that
a PMDA which does not promptly respond (ie not within the first "-q"
pmcd(1) option seconds) is a version 1.x PMDA.
It may be time to retire 1.x PMDA support?
This issue is dodged to some extent by demanding that pmdaConnect() has
been called before pmdaControl() ... so the creds pdu and version
handshake is done ... pmcd should never see a timeout at this point.
Independent of that, 1.x PMDA support can probably be sent to the clean
land fill.
...
BTW, it would suit the perl and python APIs if they could do this one
metric/indom at a time - currently they expose APIs behaving like that,
and the wrapper APIs perform the table building internally.
I doubt that this will be needed ... based on a quick look at the Perl
wrappers for libpcp_pmda, it seems the wrappers maintain private copies
of the indomtab and metrictab and do not use the ones hanging of the
pmdaInterface struct.
But there is another problem in the Perl wrapper ... pmdaInit() and
pmdaConnect() are both done in the run() method, immediately before
calling local_pmdaMain(). So we'd need an optional connect() method to
do the pmdaInit() and pmdaConnect(), then conditional code in run() to
not do this again.
With these changes something like this should just work (tm) ...
$pmda = PCP::PMDA->new(...);
$pmda->set_user('pcp'); # optional
$pmda->connect;
# long think happens here
$pmda->add_metric(...)
# etc
$pmda->add_indom(...)
# etc
$pmda->run;
If python works the same way, I'd suggest dropping pmdaSetIndoms() and
pmdaSetMetrics() as they add no value (C programmers can do this
directly already).
=== PMDA has to have a big think after start up ===
...
First call to pmdaControl() uses PMDA_CONTROL_NOREADY which forces the
NOTREADY? (typo?)
*nod*, ta.
Its not really stated, but I guess this will mean that pmcd will now
begin to propagate PM_ERR_PMDANOTREADY back to clients, for the subset
of PMIDs that the tardy PMDA should have serviced? I think thats OK,
just wanted to be sure I have that bit understood.
That is correct. At the moment under the same circumstances, it might
work, or the PMDA might be unilaterally terminated by pmcd.
We may want to tweak the wording on the error message:
$ pmerr -l | grep PMDA
-13394 PM_ERR_PMDANOTREADY PMDA is not yet ready to respond to requests
-13393 PM_ERR_PMDAREADY PMDA is now responsive to requests
As its now not going to be used only for PMDA startup (if my above
assumptions are correct), we should drop the "yet" from that first
message.
*nod*
|