libelektra: Cache problems

I still highly suspect that these disabled parts of kdbGet will cause problems with procgetstroage plugins.

https://github.com/ElektraInitiative/libelektra/blob/2734034e287fd6d657ce08b5257a6e7836569cf1/src/libs/elektra/kdb.c#L1005-L1016

However, I cannot verify that, because I simply cannot produce a cache hit. This is because a cache miss is caused, if the resolver returns NO_UPDATE for any of the backends.

https://github.com/ElektraInitiative/libelektra/blob/2734034e287fd6d657ce08b5257a6e7836569cf1/src/libs/elektra/kdb.c#L498-L500

A cache hit only happens, if CACHE_HIT was returned for all backends.

https://github.com/ElektraInitiative/libelektra/blob/2734034e287fd6d657ce08b5257a6e7836569cf1/src/libs/elektra/kdb.c#L510-L514

Not sure, whether this is intended or not. I also couldn’t find any test cases for the cache, through which I could find out how to get a cache hit.

My suspicion of the bug in kdbGet should be verifiable with the examples/gopts example. If there is some way that its kdbGet call executes the “cache hit” or “no update” branches, the gopts plugin won’t be called and command-line options will not be reported correctly.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 19 (19 by maintainers)

Commits related to this issue

doc: update relase notes, closes #2806 — committed to mpranj/libelektra by mpranj 5 years ago
doc: update relase notes, closes #2806 — committed to mpranj/libelektra by mpranj 5 years ago

Most upvoted comments

would it be enough to simply cut “proc/”

That should be done before caching in any case. proc keys are process specific so caching across processes makes no sense.

let the PROC positions run in case of cache hits

Should be enough for now.

kodebach on Jun 25, 2019

If you know of a specification of the global plugin positions, please refer me to it

I don’t know of any specification either. I just know about procgetstorage because I created it for gopts.

What seems to be another problem to me here are contradicting design goals. […]

That it is true, but right now I think just running procgetstorage should be good enough. It is not good solution, but until a better solution is found I think it is a good compromise.

Are these the same as in NO_UPDATE or do you mean literally all positions here?

The keys from procgetstorage don’t belong to backend, so just running the global plugins like in NO_UPDATE right now, should be fine.

kodebach on Jun 24, 2019

However, I cannot verify that, because I simply cannot produce a cache hit.

It should be quite easy to reproduce a cache hit: simply mount only supported plugins in one mountpoint and then do kdb get on this mountpoint.

markus2330 on Jun 24, 2019

Not sure, whether this is intended or not.

It is intended, yes. Without even testing it, I also think that you are right with your suspicion.

The current implementation (the diabled parts) yield about 80x improvement vs. about 10x improvement when the positions are run every time. The slow part was mostly spec afair. This is why we chose to disable these positions, as nobody was using them and the spec plugin was slow there.

If you feel like something essential was disabled, feel free to enable it again. If the plugins at that position are fast, it won‘t even be noticed.

mpranj on Jun 23, 2019