mridulm commented on code in PR #43502:
URL: https://github.com/apache/spark/pull/43502#discussion_r1391361132
##########
common/kvstore/src/main/java/org/apache/spark/util/kvstore/LevelDBIterator.java:
##########
@@ -182,23 +193,36 @@ public boolean skip(long n) {
@Override
public synchronized void close() throws IOException {
- db.notifyIteratorClosed(this);
+ db.notifyIteratorClosed(it);
if (!closed) {
- it.close();
- closed = true;
- next = null;
+ try {
+ it.close();
+ } catch (UncheckedIOException uncheckedIOException) {
+ throw uncheckedIOException.getCause();
+ } finally {
+ closed = true;
+ next = null;
+ cancelResourceClean();
+ }
}
}
/**
- * Because it's tricky to expose closeable iterators through many internal
APIs, especially
- * when Scala wrappers are used, this makes sure that, hopefully, the JNI
resources held by
- * the iterator will eventually be released.
+ * Prevent ResourceCleaner from actually releasing resources after close it.
*/
- @SuppressWarnings("deprecation")
- @Override
- protected void finalize() throws Throwable {
- db.closeIterator(this);
+ private void cancelResourceClean() {
+ this.resourceCleaner.setStartedToFalse();
+ this.cleanable.clean();
Review Comment:
In other words, what I am trying to understand is (should have phrased it
better :) ) what is the overhead/issues with cleaner ending up invoking this as
its normal case.
(Agree with your rationale btw - makes sense to evict it from queue).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
