anoopsjohn commented on a change in pull request #3332:
URL: https://github.com/apache/hbase/pull/3332#discussion_r642750975
##########
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/AbstractFSWAL.java
##########
@@ -1190,9 +1201,18 @@ public OptionalLong getLogFileSizeIfBeingWritten(Path
path) {
try {
Path currentPath = getOldPath();
if (path.equals(currentPath)) {
+ // Currently active path.
W writer = this.writer;
return writer != null ? OptionalLong.of(writer.getSyncedLength()) :
OptionalLong.empty();
} else {
+ W temp = inflightWALClosures.get(path.getName());
+ if (temp != null) {
Review comment:
Sorry for not making clear.
What we are in effect doing is, when the WAL file is not yet closed, we get
the length from writer which tracks the synced length. Once the WAL file is
closed, (we know that from the output of this method) there is different logic.
(I have not seen that full area though). Now with the async close, it is
possible that when this method execution is at Line 1208, the close is not over
but before we return from this method, the WAL file is really closed. Still
we will return a value and system thinks WAL file is still active one and
undergo related logic. It may be very much fine in those places. But I just
wanted to make sure we double check.
With sync close, this method and the writer close all were having a common
lock. (rollWriterLock). The entire rollWriter(boolean force) is under that
lock and cur writer close was within it.
Hope am making it clear now (?)
Again it may be very much fine only. But just can see.
--
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:
us...@infra.apache.org
