I was sanity checking some stuff about how we deal with '_version_'
tracking (per shard) and noticed that VersionInfo.updateClock is not
called anywhere in the code base...
public void updateClock(long clock) {
synchronized (clockSync) {
vclock = Math.max(vclock, clock);
}
}
FYI: DUP generates new version values by calling getNewClock() which
updates & returns a new value for the 'vclock' variable based on
currentTimeMillis() -- but ensures the new values is never less then the
old value, falling back to 'vclock + 1' if neccessary. But on server
start, 'vclock' is just the uninitialized value of '0'
This is a little disconcerting, because it means -- AFAICT -- that "new
version" values generated after a restart, may potenially be lower
then existing versions already in the index (or update log) ... that
potential existing in the situation of backwards clock drift.
Practically speaking I doubt this has ever caused any actual problems --
but it strikes me as peculualr that we don't have any code anywhere
calling this existing method to try and prevent this situation from
occuring -- particularly since we know what the highest existing version
is, and we have code paths that call methods like
'VersionInfo.seedBucketsWithHighestVersion()' various places to ensure we
track the highest known version.
So why doesn't seedBucketsWithHighestVersion() (or something like it
used on startup) just call updateClock() with the known highest version
value?
(FWIW: updateClock was added in 9fed484fb108 where it seems to have
already been dead code in that commit)
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org
