siddharthteotia commented on a change in pull request #4418: Fix potential
resource leak in the way we close a collection of closeables
URL: https://github.com/apache/incubator-pinot/pull/4418#discussion_r303621842
##########
File path:
pinot-core/src/main/java/org/apache/pinot/core/io/writer/impl/FixedByteSingleValueMultiColWriter.java
##########
@@ -99,9 +100,12 @@ public void setBytes(int row, int col, byte[] bytes) {
indexDataBuffer.readFrom(offset, bytes);
}
+ @Override
public void close()
throws IOException {
- this.indexDataBuffer.close();
- this.indexDataBuffer = null;
+ if (this.indexDataBuffer != null) {
Review comment:
I had initially done that -- removed the setting to null and made it final.
However, @mcvsubbu brought up a scenario in context of multi-threading to
explain why we were setting to null intially. Looks like if two threads race in
a particular way -- where one does a close and does not set it to null and soon
after some other thread invokes a set***() operation on this class, then it
will use the non-null buffer and invoke some set operation on it which may lead
to arbitrary errors/bugs as opposed to hitting NPE if the first thread sets it
to null. Based on this I reverted back to old behavior and made it non-final .
I agree that PinotDataBuffer.close() is final and so we don't need the if
check.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
