Project

General

Profile

Actions

Bug #12988

closed

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

Added by François ARMAND over 5 years ago. Updated over 5 years ago.

Status:
Released
Priority:
N/A
Category:
Web - Nodes & inventories
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
0
Name check:
Fix check:
Regression:

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 1 (0 open1 closed)

Related to Rudder - Bug #12474: root node disapeared while upgrading from 4.1 to 4.3 on debian 9ReleasedVincent MEMBRÉActions
Actions #1

Updated by François ARMAND over 5 years ago

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

Updated by François ARMAND over 5 years 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)

Actions #3

Updated by François ARMAND over 5 years 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.

Actions #4

Updated by François ARMAND over 5 years ago

  • Status changed from New to In progress
Actions #5

Updated by François ARMAND over 5 years 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
Actions #6

Updated by Rudder Quality Assistant over 5 years ago

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

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 4.3.4 to 4.3.3
Actions #8

Updated by François ARMAND over 5 years ago

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

Updated by François ARMAND over 5 years ago

  • Status changed from Pending technical review to Pending release
Actions #10

Updated by Vincent MEMBRÉ over 5 years ago

  • Status changed from Pending release to Released

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

Actions

Also available in: Atom PDF