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

Initialize AbstractTestQueryFramework lazily #12188

Closed

Conversation

findepi
Copy link
Member

@findepi findepi commented Apr 29, 2022

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 PR 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.

@findepi findepi force-pushed the findepi/fix-class-ordering-maybe branch from 5aee9a0 to 213587e Compare April 29, 2022 10:49
@findepi findepi force-pushed the findepi/fix-class-ordering-maybe branch 3 times, most recently from 3394490 to 562c77c Compare April 29, 2022 14:50
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.
@findepi findepi force-pushed the findepi/fix-class-ordering-maybe branch from 562c77c to eb05bfd Compare April 29, 2022 14:51
@findepi
Copy link
Member Author

findepi commented Apr 29, 2022

i added a @BeforeMethod to trigger initialization to avoid subclasses having to invoke initIfNeeded.
there will still be cases where this is needed -- subclasses with @BeforeClass -- but hopefully minimal

however, @BeforeMethod is generally forbidden in a context of a concurrent. This particular case is safe though (synchronized & idempotent), so i added ReportMultiThreadedBeforeOrAfterMethod.Suppress annotation.

@findepi findepi added the no-release-notes This pull request does not require release notes entry label Apr 29, 2022
@findepi
Copy link
Member Author

findepi commented Apr 29, 2022

@hashhar suggested that simply switching to air.test.parallel=instances may be enough of a solution (i.e. until we have surefire with https://issues.apache.org/jira/browse/SUREFIRE-1967 in use).

@hashhar @findinpath let me know your feedback from the testing

@findepi findepi marked this pull request as draft April 29, 2022 15:06
@findepi
Copy link
Member Author

findepi commented Apr 29, 2022

converted to draft. May be unnecessary after #12192 .

@findepi findepi closed this Aug 24, 2022
@findepi findepi deleted the findepi/fix-class-ordering-maybe branch August 24, 2022 09:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla-signed no-release-notes This pull request does not require release notes entry
Development

Successfully merging this pull request may close these issues.

3 participants