-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Initialize AbstractTestQueryFramework lazily #12188
Conversation
Access `queryRunner`, `h2QueryRunner` and `queryAssertions` with getters.
testing/trino-testing/src/main/java/io/trino/testing/AbstractTestQueryFramework.java
Outdated
Show resolved
Hide resolved
5aee9a0
to
213587e
Compare
testing/trino-testing/src/main/java/io/trino/testing/AbstractTestQueryFramework.java
Show resolved
Hide resolved
testing/trino-testing/src/main/java/io/trino/testing/AbstractTestQueryFramework.java
Outdated
Show resolved
Hide resolved
3394490
to
562c77c
Compare
Previously the `AbstractTestQueryFramework` was initialized with `@BeforeClass`. This was a clean approach but led to surefire+TestNG problem https://issues.apache.org/jira/browse/SUREFIRE-1967: multiple test instances being initialized and kept around while only two (or whatever test parallelism is) are actually needed. This in turn led to tests potentially exhausting available memory and failing with OOM. This commit tries to workaround this problem by introducing lazy initialization in `AbstractTestQueryFramework`. It has not been verified whether this solves the problem. Also, timing of class tear-down wasn't verified either.
562c77c
to
eb05bfd
Compare
i added a however, |
@hashhar suggested that simply switching to @hashhar @findinpath let me know your feedback from the testing |
converted to draft. May be unnecessary after #12192 . |
Previously the
AbstractTestQueryFramework
was initialized with@BeforeClass
. This was a clean approach but led to surefire+TestNGproblem https://issues.apache.org/jira/browse/SUREFIRE-1967: multiple
test instances being initialized and kept around while only two (or
whatever test parallelism is) are actually needed. This in turn led to
tests potentially exhausting available memory and failing with OOM.
This PR tries to workaround this problem by introducing lazy
initialization in
AbstractTestQueryFramework
. It has not been verifiedwhether this solves the problem. Also, timing of class tear-down wasn't
verified either.