[
https://issues.apache.org/jira/browse/HBASE-27644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17693697#comment-17693697
]
Hudson commented on HBASE-27644:
--------------------------------
Results for branch branch-2.5
[build #305 on
builds.a.o|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/305/]:
(/) *{color:green}+1 overall{color}*
----
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/305/General_20Nightly_20Build_20Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/305/JDK8_20Nightly_20Build_20Report_20_28Hadoop2_29/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/305/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 jdk11 hadoop3 checks{color}
-- For more information [see jdk11
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/305/JDK11_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Should not return false when WALKey has no following KVs while reading WAL
> file
> -------------------------------------------------------------------------------
>
> Key: HBASE-27644
> URL: https://issues.apache.org/jira/browse/HBASE-27644
> Project: HBase
> Issue Type: Bug
> Components: dataloss, wal
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Priority: Critical
> Fix For: 2.6.0, 3.0.0-alpha-4, 2.4.17, 2.5.4
>
>
> In the current implementation
> {code}
> if (!walKey.hasFollowingKvCount() || 0 == walKey.getFollowingKvCount())
> {
> LOG.trace("WALKey has no KVs that follow it; trying the next one.
> current offset={}",
> this.inputStream.getPos());
> seekOnFs(originalPosition);
> return false;
> }
> {code}
> Here we just return false, seek back to the original position. I think the
> intention here is that it means the data is not available yet and we should
> try to read them next time.
> But this class is not only used for replication, it is also used by
> splitting, return false will make the reader.next return null, and
> WALSplitter will think the WAL file has been fully read and complete the
> splitting task. If there are still other WAL entries in the file, we will
> miss reading them and cause data loss.
> And in fact, the following kv count is a field in a pb message, so it is
> impossible that now it is 0 but later it will become a value greater than 0,
> as we use writeDelimited to write the message, there is a size in front of
> the message, if we read it successfully, we can make sure the message is
> complete/ So seeking back in replication is also an useless operation.
> So here we propose we still need to return true here, so the upper layer are
> free to skip or not, but they still need to read other entries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
