Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Kea Kea
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 504
    • Issues 504
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 53
    • Merge requests 53
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • KeaKea
  • Issues
  • #1247
Closed
Open
Created May 22, 2020 by Michal Nowikowski@godfrydContributor

race condition during configuration reading from db and setting to db

When there is a series of *-set commands executed during 1second it may appear that Kea starts reading modifications from the db in the middle of this second. So it will read only part of modifications. In next turn Kea checks timestamp of modifications: ts > last_ts. Unfortunately timestamps have 1s resolution so the other part of changes will not be noticed as they happend in the same last_ts.

This can happen quite frequently when config-fetch-wait-time is set to 1s. In that case Kea checks modifications every second so there is high chance that it will get in the middle of series of modification.

It is exposed by Forge test: tests/dhcpv6/kea_only/config_backend/test_cb_v4_options.py::test_multiple_subnet_option

Edited May 22, 2020 by Michal Nowikowski
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking