Skip to content

GH-3959 follow-up: advertise node load from the remaining message stores #4593

Description

@jeremydmiller

Follow-up to #4297 (GH-3959).

The load_factor node advertisement is PostgreSQL-only. Every other message store's INodeAgentPersistence neither writes nor reads it, so a node on those stores always advertises null.

That is safe by construction — a node advertising no load is treated as having headroom, which is today's behavior — but it means CapacityAwareAssignment = true is a no-op on SQL Server, Oracle, MySQL, RavenDB, Cosmos DB and EF Core, with nothing at startup to say so.

Two pieces of work:

  1. Per-store advertisement. Add the column and the read/write for each RDBMS store (the Postgres implementation gates the column and every statement naming it on the flag, so an un-migrated database is never asked for it — worth keeping that shape). The document stores need their own answer since WolverineNode is persisted whole there.

  2. Say something when the store can't advertise. Turning the flag on against a store with no load persistence should log a warning at bootstrap rather than silently doing nothing. Related: a node that advertises null is currently treated as both having unlimited headroom and sorting into the lowest load band, which makes it the cluster's preferred placement target — see the sibling issue on that.

DatabaseConstants.LoadFactor is deliberately outside NodeColumns today because every store's readNode is a positional read over that shared list. Adding stores means either extending that carefully or keeping the by-name resolution the Postgres reader uses.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions