NodeInfoCache is precise to the second but we need it to be precise to the millisecond
In Rudder, we have a cache with all interesting node information.
That cache is based on "modifyTimeStamp" attribute value from the LDAP directory. That value is precise to the second.
But it can happen that there is several modification in the same second, and that we are looking for a cache update just at that moment. When that happen, all modification after the cache check and until a new modification is done are lost, because the cache thinks it is up-to-date, and he don't check for more.
12:00:00.123 - modification on node 1 (modifyTimestamp = 12:00:00 12:00:00.000)
12:00:00.435 - get node information for cache (last modification noted at: 12:00:00)
12:00:00.123 - modification on node 2 (modifyTimestamp = 12:00:00 12:00:00.000)
Then, on next cache up-to-date check, we look if there is modification since 12:00:01 (actually, since 12:00:00.001). There is none registered => no cache update.
This seems to be the cause of strange bugs like #12474 (not sure).
#2 Updated by François ARMAND 5 months ago
- when we look for cache up to date, we don't ask for newer strict, but newer or equals. We keep the entries with last mod == that time, and we filter them out in the result. Plus: we can't limit to 1 the number of change, it will be 1+number of entries in the previous case
- when we do modification on inventories in batch, we do an other trivial mod (or clear cacheà) 1 s after the update to force an invalidation
- we find a way to have modificationTimestamp down to the millis,
- we find a way to use the timestamp in entryCSN attribute (that one is precise to the millis)