Project

General

Profile

Bug #12988

NodeInfoCache is precise to the second but we need it to be precise to the millisecond

Added by François ARMAND 5 months ago. Updated 5 months ago.

Status:
Released
Priority:
N/A
Category:
Web - Nodes & inventories
Target version:
Severity:
User visibility:
Effort required:
Priority:
0

Description

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.

Ex:

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).


Related issues

Related to Rudder - Bug #12474: root node disapeared while upgrading from 4.1 to 4.3 on debian 9Released

Associated revisions

Revision 52d52b70 (diff)
Added by François ARMAND 5 months ago

Fixes #12988: NodeInfoCache is precise to the second but we need it to be precise to the millisecond

History

#1 Updated by François ARMAND 5 months ago

  • Related to Bug #12474: root node disapeared while upgrading from 4.1 to 4.3 on debian 9 added

#2 Updated by François ARMAND 5 months ago

Some ideas:

- 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)

#3 Updated by François ARMAND 5 months ago

So in fact, there is a very simple solution: we keep the entryCSN of the most recent entries, and when we look for update, we exclude them. Done.

#4 Updated by François ARMAND 5 months ago

  • Status changed from New to In progress

#5 Updated by François ARMAND 5 months ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from François ARMAND to Vincent MEMBRÉ
  • Pull Request set to https://github.com/Normation/rudder/pull/1989

#6 Updated by Normation Quality Assistant 5 months ago

  • Assignee changed from Vincent MEMBRÉ to François ARMAND

#7 Updated by Vincent MEMBRÉ 5 months ago

  • Target version changed from 4.3.4 to 4.3.3

#8 Updated by François ARMAND 5 months ago

  • Assignee changed from François ARMAND to Vincent MEMBRÉ

#9 Updated by François ARMAND 5 months ago

  • Status changed from Pending technical review to Pending release

#10 Updated by Vincent MEMBRÉ 5 months ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 4.3.3 which was released today.

Also available in: Atom PDF