Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zero configuration fte #14957

Merged
merged 3 commits into from
Nov 10, 2022
Merged

Conversation

arhimondr
Copy link
Contributor

Description

Set recommended settings automatically when FTE is enabled.

Non-technical explanation

Currently there are certain settings that we recommend changing when enabling FTE. This is less than ideal as it makes it more difficult to change the values of these setting in the future if necessary as they may be already configured by the user and outside of our control

Release notes

( ) This is not user-visible or docs only and no release notes are required.
( ) Release notes are required, please propose a release note for me.
(X) Release notes are required, with the following suggested text:

# Fault tolerant execution
* Set recommended settings for FTE automatically

@arhimondr
Copy link
Contributor Author

Resolves #14955

@@ -284,6 +291,11 @@ protected void setup(Binder binder)
newExporter(binder).export(PauseMeter.class).withGeneratedName();

configBinder(binder).bindConfig(MemoryManagerConfig.class);
configBinder(binder).bindConfigDefaults(MemoryManagerConfig.class, config -> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is that worth mentioning in the comment in config classes that defaults are overriden here?
Or maybe it would be more readable to define fteDefaultOverrides() in config class itself and only bind it here?

Disable redistribute_writes to have the fixes number of writer tasks
independent of the execution mode (fte or pipelined)
When FTE is enabled the system can easily retry a single task. It is no
longer necessary to be ultra conservative when acknowledging that a
certain task is lost.
@arhimondr arhimondr force-pushed the zero-configuration-fte branch from 1bf9b19 to eb973b7 Compare November 10, 2022 19:36
@arhimondr
Copy link
Contributor Author

Updated

@arhimondr arhimondr merged commit 5be7162 into trinodb:master Nov 10, 2022
@arhimondr arhimondr deleted the zero-configuration-fte branch November 10, 2022 22:27
@github-actions github-actions bot added this to the 403 milestone Nov 10, 2022
Comment on lines +486 to +489
public void applyFaultTolerantExecutionDefaults()
{
exchangeCompressionEnabled = true;
}
Copy link
Member

@hashhar hashhar Nov 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

while it's good to keep FTE defaults in same place as the other configs the method being public can lead to misuse. Config objects from Airlift are meant to be immutable so using the method anywhere except bindConfigDefaults would not have intended effects.

Would declaring a constant here and using it in bindConfigDefaults be better in that regards?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does Airlift do anything special with set* methods?

Copy link
Member

@hashhar hashhar Nov 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does Airlift do anything special with set* methods?

Not sure, didn't check.

You can obviously call set* after the fact but since the config is Guice managed and also affects other modules via conditional modules the point in time at which the set* is called can have different impact and makes reasoning about whole thing problematic.

An example is #14921 (not related to modifying the config object but regarding the effect when the config is modified can have).

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

Successfully merging this pull request may close these issues.

4 participants