Skip to content

Expose client knobs through the FDBDatabaseFactory - #4488

Open
alecgrieser wants to merge 1 commit into
FoundationDB:mainfrom
alecgrieser:04479-expose-client-knobs
Open

Expose client knobs through the FDBDatabaseFactory#4488
alecgrieser wants to merge 1 commit into
FoundationDB:mainfrom
alecgrieser:04479-expose-client-knobs

Conversation

@alecgrieser

Copy link
Copy Markdown
Collaborator

This allows FDB client knobs to be set via an API on the FDBDatabaseFactory. Knobs can be set on a running network, but we should generally encourage them to be set prior to starting the network, as some of them are not actually safe to mutate. But the FDB API is kind of unclear on which ones those are, so this does its best. There is a warning in the Javadoc discouraging souch recklnessness.

The exact set of knobs that are available are pretty vast, and they also change with different FDB versions. This does add a non-exhaustive enum, FDBClientKnob. Every value in the enum is a known client knob, and associated with it is the type we expect it to be set to. For any knob in that list, if the user tries to set the knob, we will validate that the value is of a parseable type. There is also an escape hatch, setKnob(String, String), which takes any arbitrary knob key and value. If using that secondary API, if the knob is in our known set, we validate the type. Otherwise, we let it go.

As noted in the Javadoc, FDB does not throw an error if the knob fails to pass validation (or at least, it attempts not to), and just ignores the option. We call setKnob after calling setTrace, so there's a chance that we'll at least get the TraceEvents for it if the client is configured for it.

This resolves #4479.

This allows FDB client knobs to be set via an API on the `FDBDatabaseFactory`. Knobs can be set on a running network, but we should generally encourage them to be set prior to starting the network, as some of them are not actually safe to mutate. But the FDB API is kind of unclear on which ones those are, so this does its best. There is a warning in the Javadoc discouraging souch recklnessness.

The exact set of knobs that are available are pretty vast, and they also change with different FDB versions. This does add a non-exhaustive enum, `FDBClientKnob`. Every value in the enum is a known client knob, and associated with it is the type we expect it to be set to. For any knob in that list, if the user tries to set the knob, we will validate that the value is of a parseable type. There is also an escape hatch, `setKnob(String, String)`, which takes any arbitrary knob key and value. If using that secondary API, if the knob is in our known set, we validate the type. Otherwise, we let it go.

As noted in the Javadoc, FDB does not throw an error if the knob fails to pass validation (or at least, it attempts not to), and just ignores the option. We call `setKnob` after calling `setTrace`, so there's a chance that we'll at least get the `TraceEvents` for it if the client is configured for it.

This resolves FoundationDB#4479.
@alecgrieser alecgrieser added the enhancement New feature or request label Aug 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Expose setting client knobs through FDBDatabaseFactory

1 participant