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

Check all queries returned memory on query runner teardown #11102

Merged
merged 1 commit into from
Feb 23, 2022

Conversation

losipiuk
Copy link
Member

Description

Check all queries returned memory on query runner teardown

Is this change a fix, improvement, new feature, refactoring, or other?

testing improvement

Is this a change to the core query engine, a connector, client library, or the SPI interfaces? (be specific)

tests

Related issues, pull requests, and links

fixes: #11093

Documentation

(x) No documentation is needed.
( ) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.

Release notes

(x) No release notes entries required.
( ) Release notes entries required with the following suggested text:

@cla-bot cla-bot bot added the cla-signed label Feb 18, 2022
@losipiuk losipiuk force-pushed the lo/dist-que-run-check-pools branch from ae531ba to ee82260 Compare February 18, 2022 13:59
Comment on lines 626 to 634
private void closeCloserSuppressing(Throwable exception)
{
try {
closer.close();
}
catch (IOException e) {
exception.addSuppressed(e);
}
}
Copy link
Member

Choose a reason for hiding this comment

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

io.airlift.testing.Closeables#closeAllSuppress ?

@@ -583,6 +586,15 @@ public void loadExchangeManager(String name, Map<String, String> properties)
public final void close()
{
cancelAllQueries();

try {
checkQueryMemoryReleased();
Copy link
Member

Choose a reason for hiding this comment

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

close() it not an awesome place to assert.

we could perhaps have a @AfterMethod check in TestDistributedEngineOnlyQueries, using queryRunner.getExclusiveLock()?

Copy link
Contributor

Choose a reason for hiding this comment

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

@AfterMethod might not work great as we run tests in multiple threads. How about putting it in the AbstractTestQueryFramework#close annotated with @AfterClass? (or maybe have a dedicated @AfterClass method that does just that?)

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah - I agree place is not great.
TestDistributedEngineOnlyQueries is not the only place we want this. Specifically, we want to test in Test*QueryFailureRecoveryTest.

Copy link
Member Author

Choose a reason for hiding this comment

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

@AfterClass feels less invasive. Having @AfterMethod with lock may make test execution significantly longer, due to threads waiting one for another.
Not sure we can have two @AfterClass methods (would would be the ordering). But putting that in AbstractTestQueryFramework.close() looks good to me.
There will still be some places where query runner is constructed directly (not via AbstractTestQueryFramework) which will not be subject to validation - but we can live with that I guess.

Copy link
Member

Choose a reason for hiding this comment

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

Having @AfterMethod with lock may make test execution significantly longer, due to threads waiting one for another.

i thought about that, but was more optimistic.
is it hard to measure?

note that pools should be empty immediately after query finishes, so the "assert eventually" should end real quick

Copy link
Member

Choose a reason for hiding this comment

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

But putting that in AbstractTestQueryFramework.close() looks good to me.

Looks good to me too, let's do this

Copy link
Contributor

@arhimondr arhimondr left a comment

Choose a reason for hiding this comment

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

LGTM % comments

@@ -583,6 +586,15 @@ public void loadExchangeManager(String name, Map<String, String> properties)
public final void close()
{
cancelAllQueries();

try {
checkQueryMemoryReleased();
Copy link
Contributor

Choose a reason for hiding this comment

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

@AfterMethod might not work great as we run tests in multiple threads. How about putting it in the AbstractTestQueryFramework#close annotated with @AfterClass? (or maybe have a dedicated @AfterClass method that does just that?)

closer.close();
}
catch (IOException e) {
exception.addSuppressed(e);
Copy link
Contributor

Choose a reason for hiding this comment

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

if(exception != e) as self suppression is not allowed

Copy link
Member Author

Choose a reason for hiding this comment

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

Not needed as exception cannot be IOException (IOException is checked).

@losipiuk losipiuk force-pushed the lo/dist-que-run-check-pools branch from ee82260 to 7e81ac7 Compare February 19, 2022 15:50
@losipiuk losipiuk requested a review from findepi February 21, 2022 08:38
@losipiuk losipiuk force-pushed the lo/dist-que-run-check-pools branch from 7e81ac7 to 7bc06f9 Compare February 21, 2022 08:40
@losipiuk
Copy link
Member Author

I temporarily cherry-picked #11097 here. Should fix the CI failures.

throw e;
}

afterClassCloser.close();
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this go to finally?

Copy link
Member Author

Choose a reason for hiding this comment

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

no. It would mess up exception in case closer would throw. I want to get exception from checkQueryMemoryReleased if there is one.

Copy link
Contributor

Choose a reason for hiding this comment

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

It's still feels like it is worth calling close. If close is not called the in memory cluster will remain active while the testing framework is running other test cases. Maybe put it in finally and wrap it in a try-catch?

Copy link
Member

Choose a reason for hiding this comment

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

i agree. afterClassCloser must be invoked even if checkQueryMemoryReleased fals.

Copy link
Member Author

Choose a reason for hiding this comment

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

But it is. In catch clause

Copy link
Member

Choose a reason for hiding this comment

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

right, missed that.
you could also use try() for same effect

Copy link
Member Author

Choose a reason for hiding this comment

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

true. Wil change

Copy link
Member Author

Choose a reason for hiding this comment

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

You meant like that?

Copy link
Contributor

Choose a reason for hiding this comment

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

I totally missed that the close was called. The current state looks good to me.

@losipiuk losipiuk force-pushed the lo/dist-que-run-check-pools branch from 7bc06f9 to 7793b00 Compare February 22, 2022 16:23
throw e;
}

afterClassCloser.close();
Copy link
Member

Choose a reason for hiding this comment

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

i agree. afterClassCloser must be invoked even if checkQueryMemoryReleased fals.

@losipiuk losipiuk force-pushed the lo/dist-que-run-check-pools branch from 7793b00 to 1724f93 Compare February 22, 2022 20:43
h2QueryRunner = null;
sqlParser = null;
queryAssertions = null;
try (AutoCloseable ignored = afterClassCloser) {
Copy link
Member

Choose a reason for hiding this comment

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

try (afterClassCloser)

Copy link
Member Author

Choose a reason for hiding this comment

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

Wow. 🤯 . Was that always possible?

Copy link
Member

Choose a reason for hiding this comment

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

No, not always. Initially wasn't.

@findepi
Copy link
Member

findepi commented Mar 2, 2022

Follow-up issue: #11275

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.

Assert memory pools are empty upon QueryRunner termination in integration tests
3 participants