Skip to content

Core: Support set system level properties with environmental variables - #5659

Merged
szehon-ho merged 7 commits into
apache:masterfrom
ConeyLiu:set_prop_with_env
May 24, 2023
Merged

Core: Support set system level properties with environmental variables#5659
szehon-ho merged 7 commits into
apache:masterfrom
ConeyLiu:set_prop_with_env

Conversation

@ConeyLiu

Copy link
Copy Markdown
Contributor

This add supports setting system level properties with environmental variables. For example: we could control the number of threads for the default Iceberg thread pool with java system property: iceberg.worker.num-threads or env: ICEBERG_WORKER_NUM_THREADS. This is indeed useful when we want to change those properties while the java system properties have some default settings and we do not want to change them.

@github-actions github-actions Bot added the core label Aug 29, 2022
@ConeyLiu

Copy link
Copy Markdown
Contributor Author

cc @rdblue @kbendick @szehon-ho, this is a small update, could you take a look when you are free? Thanks a lot.

@ConeyLiu ConeyLiu changed the title Core: Support set system level properties with environmental variable Core: Support set system level properties with environmental variables Aug 29, 2022
public static final String SCAN_THREAD_POOL_ENABLED = "iceberg.scan.plan-in-worker-pool";

static boolean getBoolean(String systemProperty, boolean defaultValue) {
public static final String SCAN_THREAD_POOL_ENABLED_ENV = "ICEBERG_SCAN_PLAN_IN_WORKER_POOL";

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Does this need to be explosed?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It is used by core/src/main/java/org/apache/iceberg/util/ThreadPools.java in a different package. I updated other envs to the default access level.

@zinking

zinking commented Mar 27, 2023

Copy link
Copy Markdown
Contributor

@szehon-ho @rdblue can we take another look and merge if possible ?

@szehon-ho

Copy link
Copy Markdown
Member

Hi guys, can you explain the motivation of the change? Not opposed, but reading the description but didn't quite understand it. To me, both seem to be more or less equivalent in ease-of-use (they are passed to the java process when it is spawned..)

@ConeyLiu

ConeyLiu commented Mar 28, 2023

Copy link
Copy Markdown
Contributor Author

@szehon-ho In many production environments, there are some default parameter settings for spark driver/executor java options (eg: gc parameters). And those parameters are concated into one string. This makes it difficult to overwrite or modify those parameters to set iceberg system-level properties. While with ENV settings, we could set those system-level properties separately.

@szehon-ho szehon-ho left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I see, yea spark seems to support env variables to set certain things. Left some comments.

Comment thread core/src/main/java/org/apache/iceberg/SystemProperties.java Outdated
@ConeyLiu
ConeyLiu force-pushed the set_prop_with_env branch from 0c6a8f1 to fe5a9d9 Compare April 8, 2023 03:21
Comment thread core/src/main/java/org/apache/iceberg/SystemConfigs.java
Comment thread core/src/main/java/org/apache/iceberg/util/ThreadPools.java

@szehon-ho szehon-ho left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Left some comments. While the code is cleaner now, cc @rdblue if we are ok with new public interface here

Comment thread core/src/main/java/org/apache/iceberg/SystemConfigs.java
@ConeyLiu

ConeyLiu commented May 5, 2023

Copy link
Copy Markdown
Contributor Author

Thanks @szehon-ho for the reviewing, and sorry got held up.

@szehon-ho szehon-ho left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Looks good to me, left one nit. Will wait a bit if there's any more comment, and merge if not

if (value != null) {
try {
return parseFunc.apply(value);
} catch (NumberFormatException e) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Nit: how about catch Exception , as we don't know what kind of Function we get?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Updated and add the log.

@ConeyLiu

Copy link
Copy Markdown
Contributor Author

gentle ping @szehon-ho

@szehon-ho
szehon-ho merged commit 4b8941e into apache:master May 24, 2023
@szehon-ho

Copy link
Copy Markdown
Member

Merged, thanks @ConeyLiu !

@ConeyLiu

Copy link
Copy Markdown
Contributor Author

Thanks @szehon-ho @zinking @rdblue

@ConeyLiu
ConeyLiu deleted the set_prop_with_env branch May 25, 2023 03:43
huaxingao pushed a commit that referenced this pull request Sep 1, 2026
…log message (#17812)

* Core: Remove ThreadPools.WORKER_THREAD_POOL_SIZE_PROP and correct manifest spec fallback removal version

Resolves the two remaining deprecation markers in iceberg-core that
promised action "in 1.12.0" but were missed by the removal PRs.

Remove ThreadPools.WORKER_THREAD_POOL_SIZE_PROP. The field was
deprecated in #5659 in favor of SystemConfigs.WORKER_THREAD_POOL_SIZE
and retargeted from 2.0.0 to 1.12.0 by #14392. It had no callers
anywhere in the repository outside its own declaration and no
references in the docs, and it was the only survivor of #14392's
13-file batch after #17700 removed the rest. The corresponding
java.field.removed break is recorded in .palantir/revapi.yml under the
1.11.0 baseline.

Correct the ManifestReader warning for the partition-spec-from-file-
metadata fallback to say 2.0.0 rather than 1.12.0. The fallback cannot
be honored in 1.12.0 because its only production caller is
BaseSnapshot:276, which passes a null spec map while serving
Snapshot.addedDeleteFiles(FileIO) and removedDeleteFiles(FileIO).
Those accessors are themselves already marked "@deprecated will be
removed in 2.0.0; use SnapshotChanges#builderFor(Table) instead", and
because they receive only a FileIO they structurally cannot supply a
spec map. The fallback must therefore outlive 1.12.0, and 2.0.0 aligns
its removal with that of its last caller.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants