Hi David,
----- Original Message -----
> > [...]
> > Yeah - something like that - have a look at src/libpcp_pmda/src/cache.c as
> > thats how the instance cache number stability is achieved. Perhaps we can
> > extend that with additional APIs to help us out here.
> >
>
> I've looked into the idea of using a hash/crypto hash function, and I
> just don't see a way to do it within the current api. 22-bits to encode
> the cluster/item just isn't enough, especially if we want a unique hash
> value.
*nod*.
> For the JSON PMDA, we put each JSON source in its own cluster, so it can
> support 4096 JSON sources, each with 1024 metrics.
*nod*.
> If we don't want to break the current api/abi, the JSON PMDA could just
Its OK to extend the API/ABI, but not to break it. Which should be all we
need to do here, I think. Maybe see if we can reduce the range that those
cache.c interfaces accept - the two lines with "if (inst == 0x7fffffff) {"
there look promising. If we had a h->maxinst there perhaps, instead of the
hard-coded 2^32-1 limit (may need to change the test to '>=' too) we might
be done and dusted here. That'll turn out to be a gross oversimplification
I'm sure ... but maybe, just maybe it will work.
> store its state (which JSON source maps to which cluster and which
> metrics within a source map to which item) in a file when it quits, then
> restore it at startup.
The cache routines provide mechanisms for persistence too, so we should be
able to leverage that concept here and not need to write new code, hopefully
(although I think that will need to be exposed to python land for use here,
nothing else has needed those interfaces so far).
> Is it safe to ever reuse a cluster/item?
Unfortunately not.
cheers.
--
Nathan
|