On 26/03/14 08:39, Nathan Scott wrote:
...
OK. That creds exchange happens immediately, as we discussed, so I
guess we'll need to document that we need to get through that early
protocol exchange before any long running transactions (IOW, Franks
observed pmdasystemd journald-API-takes-ridiculously-long-to-return
problem will not get fixed here). I wonder if we should tweak/add
an API to allow a PMDA to enter the creds exchange earlier than it
normally would?
For C I think the API hook is already there ... just call pmdaConnect()
(and before that pmdaInit()) earlier.
As I think I said in an earlier mail (a couple of days ago), this will
require a new method for Perl (and Python I suspect if that wrapper
follows the Perl model) to force the connect earlier than the run()
method, I suggested connect().
From the earlier mail here is the pseudo-code ...
$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;
I'd implement this so that run() calls connect() and connect() has a
one-trip guard to ensure the pmcd connection is only done once. This
way existing PMDAs (and any new ones that are not tardy starters) would
remain the same as today.
The example above needs to be tested to ensure that the add_metric() and
add_indom() logic works after the connect() ... if this is OK, then we
can add $pmda->control(..BUSY..) after the connect() call for the slow
starters.
...
Perfect. I'm wondering too if, once we have this facility available,
we should reduce that default 5 second pmcd/pmda timeout to something
much shorter (1 second or less, even) to start weeding out any badly
behaving PMDAs and improve overall sampling accuracy?
That would be good.
|