Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 634
    • Issues 634
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 89
    • Merge requests 89
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source ProjectsISC Open Source Projects
  • BINDBIND
  • Issues
  • #2289
Closed
Open
Issue created Nov 17, 2020 by Brian Conry@bconryContributor

cache dump sometimes reports nonsense values with "stale (will be retained for %u more seconds)"

Several customers have reported this issue, but the cause had been completely baffling.

Examples include:

; stale (will be retained for 4294362497 more seconds)

While reviewing the relevant areas of the code for other issues, I realized that the decision about whether or not to report the record as stale, and report how long it will be retained for (as modified by the recorded stale intervals), is based solely on the STALE flag in the header.

This is an accurate decision, but I wonder if this might lead to odd results if the record expiration is actually in the future because it has been forcibly expired due to the cache being overmem.

I've also wondered if there might be some incorrect reporting if/when the max-stale-ttl is changed after data has been added to the cache.

I will investigate both of these issues further using customer data I already have on hand, but I won't complain if it is fixed before I get to it.

Assignee
Assign to
Time tracking