nsivabalan commented on code in PR #18834:
URL: https://github.com/apache/hudi/pull/18834#discussion_r3305969356
##########
hudi-common/src/main/java/org/apache/hudi/common/table/view/SpillableMapBasedFileSystemView.java:
##########
@@ -225,14 +225,18 @@ protected void
removeReplacedFileIdsAtInstants(Set<String> instants) {
}
@Override
- public void close() {
+ protected void closeResources() throws Exception {
+ // Close ExternalSpillableMaps (which hold RocksDB handles) while the
writeLock is held
+ // by AbstractTableFileSystemView.close(). This prevents a race where a
concurrent reader
+ // holding readLock could be mid-call in RocksDBDAO.put() when the handles
are cleared,
+ // causing a NullPointerException at RocksDB.put(null_handle, ...).
closeFileGroupsMapIfPresent();
closePendingClusteringMapIfPresent();
closePendingCompactionMapIfPresent();
closePendingLogCompactionMapIfPresent();
closeBootstrapFileMapIfPresent();
closeReplaceInstantsMapIfPresent();
- super.close();
+ super.closeResources();
Review Comment:
+1
either we keep close() in RocksDbBasedFileSystemView and impl as below
```
@Override
public void close() {
try {
LOG.info("Closing Rocksdb !!");
writeLock.lock();
closed = true;
closeResources();
clear();
rocksDB.close();
LOG.info("Closed Rocksdb !!");
} catch (Exception e) {
throw new HoodieException("Unable to close file system view", e);
} finally {
writeLock.unlock();
}
}
```
or we need to ensure we hold the writeLock even when updating `closed = true`
--
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]
