On 06/21/2016 03:19 AM, Ken McDonell wrote:
Apologies Dave for not responding earlier ...
#include <stdexcuses.h>
No problem.
-----Original Message-----
From: Dave Brolley [mailto:brolley@xxxxxxxxxx]
Sent: Tuesday, 31 May 2016 5:48 AM
1. I'm looking at the code in src/pmlogger/src/fetch.c where 'if
(changed & PMCD_ADD_AGENT)' is handled. It seems to me that this test
which adds a mark record in the case a pmda (re)starts (outside the
loop which handles the received pdus) is too late, since pdus
representing several potentially changed/reset metrics may have been
erroneously logged before then. Should the test not be made, and the
mark record not be generated inside the loop at the point at which the
change is first noticed?
I think the code is wrong.
The protocol is ...
-> client send request
<- pmcd sends error pdu with error code > 0 AND
<- pmcd sends response pdu
So __pmGetPDU loop in fetch.c gets and decodes these in the correct order, but
the test and putmark() call should be inside the loop before the pmResult is
output.
Great. That's what I thought too.
2. I'm considering two possibilities for checking the consistency of
the PMNS+metadata:
1. Check the consistency of all metrics in all task list items
at this point
* pro: It gets the check out of the way with no
additional infrastructure at the point of the change
* con: It might be too much work to do in shot at this
point in the fetch/log cycle?
I'd vote for Plan 1. (which I understand you've already decided on).
Just one thing, what sort of "consistency" checks are you planning here? And I
assume these are hiding behind the putmark() guard, correct?
Essentially the same consistency checks that we do at a multi-archive
boundary. For each metric in each task list entry we check that the
pmid, type, instance domain, units and semantics have not changed. If
any one of the metrics fails any of these tests, then we would shut down
the pmlogger instance and allow the normal mechanisms to start a new
one. If all of the metrics pass all of the tests, then pmlogger
generates a <mark> record and continues.
Thanks,
Dave
|