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

GH-5159 close child of GroupIterator #5160

Merged

Conversation

frensjan
Copy link
Contributor

GitHub issue resolved: #5159

Briefly describe the changes proposed in this PR:

I've added the child argument's iterator as (volatile) field in the GroupIterator so that it can be closed while building entires.


PR Author Checklist (see the contributor guidelines for more details):

  • my pull request is self-contained
  • I've added tests for the changes I made
  • I've applied code formatting (you can use mvn process-resources to format from the command line)
  • I've squashed my commits where necessary
  • every commit message starts with the issue number (GH-xxxx) followed by a meaningful description of the change

try {
cf.close();
} finally {
argumentsIter.close();
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like you need to add:

var argumentsIter = this.argumentsIter;
if(argumentsIter != null) argumentsIter.close() 

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Obviously! Thanks Håvard.

@hmottestad
Copy link
Contributor

Screenshot 2024-10-28 at 09 08 57

Should we check if the current iterator is closed within the loop? We have the isClosed() method we can call. For performance reasons the backing variables isn't volatile, but it should still get updated eventually. The variable is set before the handleClose() method is called, so it would be a nice safety net in case the argumentsIter doesn't close correctly for some reason.

@hmottestad
Copy link
Contributor

Thanks for this fix. Very good catch and a nice and clean solution!

@frensjan
Copy link
Contributor Author

Should we check if the current iterator is closed within the loop? We have the isClosed() method we can call. For performance reasons the backing variables isn't volatile, but it should still get updated eventually. The variable is set before the handleClose() method is called, so it would be a nice safety net in case the argumentsIter doesn't close correctly for some reason.

Yes, that's good to add.

@frensjan frensjan force-pushed the GH-5159-close-group-iterator-arg branch from 9f6e7e9 to 6d97c2a Compare October 28, 2024 17:49
@JervenBolleman
Copy link
Contributor

LGTM! thank you @frensjan

cf.close();
} finally {
if (argumentsIter != null) {
argumentsIter.close();
Copy link
Contributor

@hmottestad hmottestad Nov 1, 2024

Choose a reason for hiding this comment

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

Cant argumentsIter still be null? It could be set to null between this line and the null check above.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, indeed. Missed that in your initial comment.

iteratorThread.start();
assertThat(iterating.await(5, TimeUnit.SECONDS)).isTrue();
groupIterator.close();
assertThat(closed.await(5, TimeUnit.SECONDS)).isTrue();
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we also assert that the iteratorThread is no longer alive? So we are sure that we're not leaking a thread.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The test was in fact leaking a Thread. Just fixed it.

@frensjan frensjan force-pushed the GH-5159-close-group-iterator-arg branch from 6d97c2a to c58c287 Compare November 2, 2024 20:12
@frensjan frensjan force-pushed the GH-5159-close-group-iterator-arg branch from c58c287 to 384d1b5 Compare November 2, 2024 21:12
@hmottestad hmottestad merged commit e25913a into eclipse-rdf4j:main Nov 3, 2024
9 checks passed
@hmottestad
Copy link
Contributor

Thanks @frensjan !

I've merged the PR and it'll ve part of the next bug fix release which is due any day now.

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

Successfully merging this pull request may close these issues.

GroupIterator doesn't close child iterator
3 participants