Skip to content

HBASE-29611: With FILE based SFT, the list of HFiles we maintain in .filelist is n… - #7361

Merged
anmolnar merged 2 commits into
apache:HBASE-29081from
sharmaar12:sft_issue
Oct 27, 2025
Merged

HBASE-29611: With FILE based SFT, the list of HFiles we maintain in .filelist is n…#7361
anmolnar merged 2 commits into
apache:HBASE-29081from
sharmaar12:sft_issue

Conversation

@sharmaar12

Copy link
Copy Markdown
Contributor

…ot getting updated for read replica

Link to JIRA: https://issues.apache.org/jira/browse/HBASE-29611

Description:
Steps to Repro (For detailed steps, check JIRA):

  • Create two clusters on the same storage location.
  • Create table on active, then refresh meta on the read replica to get the table meta data updated.
  • Add some rows and flush on the active cluster, do refresh_hfiles on the read replica and scan table.
  • If you now again add the rows in the table on active and do refresh_hfiles then the rows added are not visible in the read replica.

Cause:
The refresh store file is a two step process:

  1. Load the existing store file from the .filelist (choose the file with higher timestamp for loading)
  2. refresh store file internals (clean up old/compacted files, replace store file in .filelist)

In the current scenario, what is happening is that for the first time read-replica is loading the list of Hfiles from the file in .filelist created by active cluster but then it is creating the new file with greater timestamp. Now we have two files in .filelist. On the subsequent flush from active the file in .filelist created by the active gets updated but the file created by read-replica is not. While loading in the refresh_hfiles as we take the file with higher timestamp the file created by read-replica for the first time gets loaded which does not have an updated list of hfiles.

Fix:
As we just wanted the file from active to be loaded anytime we perform refresh store files, we must not create a new file in the .filelist from the read-replica, in this way we will stop the timestamp mismatch.

Also we don't want to initialize the tracker file (StoreFileListFile.java:load()) from read-replica as we are not writing it hence we have added check for read only property in StoreFileTrackerBase.java:load()

@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

@sharmaar12sharmaar12 changed the title With FILE based SFT, the list of HFiles we maintain in .filelist is n…HBASE-29611: With FILE based SFT, the list of HFiles we maintain in .filelist is n…Oct 14, 2025
@Apache-HBase

This comment has been minimized.

@Apache-HBase

This comment has been minimized.

@Apache-HBase

Copy link
Copy Markdown

🎊 +1 overall

VoteSubsystemRuntimeLogfileComment
+0 🆗reexec0m 51sDocker mode activated.
_ Prechecks _
+1 💚dupname0m 1sNo case conflicting files found.
+0 🆗codespell0m 0scodespell was not available.
+0 🆗detsecrets0m 0sdetect-secrets was not available.
+1 💚@author0m 0sThe patch does not contain any @author tags.
+1 💚hbaseanti0m 0sPatch does not have any anti-patterns.
_ HBASE-29081 Compile Tests _
+1 💚mvninstall5m 32sHBASE-29081 passed
+1 💚compile5m 18sHBASE-29081 passed
-0 ⚠️checkstyle0m 23s/buildtool-branch-checkstyle-hbase-server.txtThe patch fails to run checkstyle in hbase-server
+1 💚spotbugs2m 36sHBASE-29081 passed
+1 💚spotless1m 15sbranch has no errors when running spotless:check.
_ Patch Compile Tests _
+1 💚mvninstall3m 43sthe patch passed
+1 💚compile4m 4sthe patch passed
+1 💚javac4m 4sthe patch passed
+1 💚blanks0m 0sThe patch has no blanks issues.
-0 ⚠️checkstyle0m 18s/buildtool-patch-checkstyle-hbase-server.txtThe patch fails to run checkstyle in hbase-server
+1 💚spotbugs2m 6sthe patch passed
+1 💚hadoopcheck12m 52sPatch does not cause any errors with Hadoop 3.3.6 3.4.0.
+1 💚spotless0m 47spatch has no errors when running spotless:check.
_ Other Tests _
+1 💚asflicense0m 12sThe patch does not generate ASF License warnings.
48m 7s
SubsystemReport/Notes
DockerClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7361/4/artifact/yetus-general-check/output/Dockerfile
GITHUB PR#7361
JIRA IssueHBASE-29611
Optional Testsdupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless
unameLinux 365fbfb48f0b 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build toolmaven
Personalitydev-support/hbase-personality.sh
git revisionHBASE-29081 / de147a0
Default JavaEclipse Adoptium-17.0.11+9
Max. process+thread count83 (vs. ulimit of 30000)
modulesC: hbase-server U: hbase-server
Console outputhttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7361/4/console
versionsgit=2.34.1 maven=3.9.8 spotbugs=4.7.3
Powered byApache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

@Apache-HBase

Copy link
Copy Markdown

🎊 +1 overall

VoteSubsystemRuntimeLogfileComment
+0 🆗reexec0m 31sDocker mode activated.
-0 ⚠️yetus0m 3sUnprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck
_ Prechecks _
_ HBASE-29081 Compile Tests _
+1 💚mvninstall3m 37sHBASE-29081 passed
+1 💚compile1m 3sHBASE-29081 passed
+1 💚javadoc0m 30sHBASE-29081 passed
+1 💚shadedjars6m 13sbranch has no errors when building our shaded downstream artifacts.
_ Patch Compile Tests _
+1 💚mvninstall3m 10sthe patch passed
+1 💚compile1m 0sthe patch passed
+1 💚javac1m 0sthe patch passed
+1 💚javadoc0m 29sthe patch passed
+1 💚shadedjars6m 6spatch has no errors when building our shaded downstream artifacts.
_ Other Tests _
+1 💚unit235m 52shbase-server in the patch passed.
263m 8s
SubsystemReport/Notes
DockerClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7361/4/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile
GITHUB PR#7361
JIRA IssueHBASE-29611
Optional Testsjavac javadoc unit compile shadedjars
unameLinux 998a791fdf9e 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build toolmaven
Personalitydev-support/hbase-personality.sh
git revisionHBASE-29081 / de147a0
Default JavaEclipse Adoptium-17.0.11+9
Test Resultshttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7361/4/testReport/
Max. process+thread count3404 (vs. ulimit of 30000)
modulesC: hbase-server U: hbase-server
Console outputhttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7361/4/console
versionsgit=2.34.1 maven=3.9.8
Powered byApache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

@anmolnaranmolnar left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, basically you want to act like secondary replicas in the read-only case, right?
Would you please add unit tests?

@sharmaar12

Copy link
Copy Markdown
ContributorAuthor

@anmolnar

So, basically you want to act like secondary replicas in the read-only case, right?

Technically, in some cases, Yes. But main aim is to prevent recreation of tracker file with higher timestamp on refresh.

Added unit tests please review.

@Apache-HBase

Copy link
Copy Markdown

🎊 +1 overall

VoteSubsystemRuntimeLogfileComment
+0 🆗reexec0m 14sDocker mode activated.
_ Prechecks _
+1 💚dupname0m 0sNo case conflicting files found.
+0 🆗codespell0m 0scodespell was not available.
+0 🆗detsecrets0m 0sdetect-secrets was not available.
+1 💚@author0m 0sThe patch does not contain any @author tags.
+1 💚hbaseanti0m 0sPatch does not have any anti-patterns.
_ HBASE-29081 Compile Tests _
+1 💚mvninstall5m 52sHBASE-29081 passed
+1 💚compile5m 14sHBASE-29081 passed
-0 ⚠️checkstyle0m 34s/buildtool-branch-checkstyle-hbase-server.txtThe patch fails to run checkstyle in hbase-server
+1 💚spotbugs2m 24sHBASE-29081 passed
+1 💚spotless1m 11sbranch has no errors when running spotless:check.
_ Patch Compile Tests _
+1 💚mvninstall5m 0sthe patch passed
+1 💚compile5m 0sthe patch passed
+1 💚javac5m 0sthe patch passed
+1 💚blanks0m 0sThe patch has no blanks issues.
-0 ⚠️checkstyle0m 33s/buildtool-patch-checkstyle-hbase-server.txtThe patch fails to run checkstyle in hbase-server
+1 💚spotbugs2m 40sthe patch passed
+1 💚hadoopcheck15m 42sPatch does not cause any errors with Hadoop 3.3.6 3.4.0.
+1 💚spotless1m 5spatch has no errors when running spotless:check.
_ Other Tests _
+1 💚asflicense0m 17sThe patch does not generate ASF License warnings.
55m 24s
SubsystemReport/Notes
DockerClientAPI=1.48 ServerAPI=1.48 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7361/5/artifact/yetus-general-check/output/Dockerfile
GITHUB PR#7361
JIRA IssueHBASE-29611
Optional Testsdupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless
unameLinux 6c0aeab6c4e0 6.8.0-1024-aws #26~22.04.1-Ubuntu SMP Wed Feb 19 06:54:57 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Build toolmaven
Personalitydev-support/hbase-personality.sh
git revisionHBASE-29081 / 737c33c
Default JavaEclipse Adoptium-17.0.11+9
Max. process+thread count71 (vs. ulimit of 30000)
modulesC: hbase-server U: hbase-server
Console outputhttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7361/5/console
versionsgit=2.34.1 maven=3.9.8 spotbugs=4.7.3
Powered byApache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

@Apache-HBase

Copy link
Copy Markdown

💔 -1 overall

VoteSubsystemRuntimeLogfileComment
+0 🆗reexec0m 12sDocker mode activated.
-0 ⚠️yetus0m 4sUnprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck
_ Prechecks _
_ HBASE-29081 Compile Tests _
+1 💚mvninstall5m 34sHBASE-29081 passed
+1 💚compile1m 44sHBASE-29081 passed
+1 💚javadoc0m 55sHBASE-29081 passed
+1 💚shadedjars9m 57sbranch has no errors when building our shaded downstream artifacts.
_ Patch Compile Tests _
+1 💚mvninstall5m 3sthe patch passed
+1 💚compile1m 34sthe patch passed
+1 💚javac1m 34sthe patch passed
+1 💚javadoc0m 45sthe patch passed
+1 💚shadedjars9m 6spatch has no errors when building our shaded downstream artifacts.
_ Other Tests _
-1 ❌unit19m 44s/patch-unit-hbase-server.txthbase-server in the patch failed.
56m 47s
SubsystemReport/Notes
DockerClientAPI=1.48 ServerAPI=1.48 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7361/5/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile
GITHUB PR#7361
JIRA IssueHBASE-29611
Optional Testsjavac javadoc unit compile shadedjars
unameLinux 1f20fdf0933b 6.8.0-1024-aws #26~22.04.1-Ubuntu SMP Wed Feb 19 06:54:57 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Build toolmaven
Personalitydev-support/hbase-personality.sh
git revisionHBASE-29081 / 737c33c
Default JavaEclipse Adoptium-17.0.11+9
Test Resultshttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7361/5/testReport/
Max. process+thread count785 (vs. ulimit of 30000)
modulesC: hbase-server U: hbase-server
Console outputhttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7361/5/console
versionsgit=2.34.1 maven=3.9.8
Powered byApache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

…filelist is not getting updated for read replica
Link to JIRA: https://issues.apache.org/jira/browse/HBASE-29611
Description:
Steps to Repro (For detailed steps, check JIRA):
- Create two clusters on the same storage location.
- Create table on active, then refresh meta on the read replica to get the table meta data updated.
- Add some rows and flush on the active cluster, do refresh_hfiles on the read replica and scan table.
- If you now again add the rows in the table on active and do refresh_hfiles then the rows added are not visible in the read replica.
Cause:
The refresh store file is a two step process:
1. Load the existing store file from the .filelist (choose the file with higher timestamp for loading)
2. refresh store file internals (clean up old/compacted files, replace store file in .filelist)
In the current scenario, what is happening is that for the first time read-replica is loading the list of Hfiles from the file in .filelist created by active cluster but then it is creating the new file with greater timestamp. Now we have two files in .filelist. On the subsequent flush from active the file in .filelist created by the active gets updated but the file created by read-replica is not. While loading in the refresh_hfiles as we take the file with higher timestamp the file created by read-replica for the first time gets loaded which does not have an updated list of hfiles.
Fix:
As we just wanted the file from active to be loaded anytime we perform refresh store files, we must not create a new file in the .filelist from the read-replica, in this way we will stop the timestamp mismatch.
NOTE:
Also we don't want to initialize the tracker file (StoreFileListFile.java:load()) from read-replica as we are not writing it hence we have added check for read only property in StoreFileTrackerBase.java:load()

@wchevreuilwchevreuil left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, lgtm. Just need to fix the issue with the newly added UT and a minor comment I. have suggested.

Comment on lines +104 to +107
if (
isPrimaryReplica && !conf.getBoolean(HConstants.HBASE_GLOBAL_READONLY_ENABLED_KEY,
HConstants.HBASE_GLOBAL_READONLY_ENABLED_DEFAULT)
) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add same check to the add and set method? It would give an extra safeguard just in case these methods are inadvertently called on read-replica.

@sharmaar12sharmaar12Oct 22, 2025

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wchevreuil We haven't added any prevention mechanism which will avoid calls to add and set function in read-only mode, so are you suggesting to add it to these methods?

Without these unit tests will always fails, as here I am deliberately calling them in test function.

@anmolnaranmolnarOct 22, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to clone the behavior of secondary replicas for the read-only mode, which makes perfect sense to me, I think you should follow it everywhere in this class. In addition to add(), set() and replace() methods, you might want to add the same safeguard to createWriter() method as well. Could be also useful to extract the check in a separate method to reduce code duplication.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@anmolnar@wchevreuil
Added code changes as suggested. Please review.

I do see there are two more functions createReference and removeStoreFiles, do you think we should safeguard these functions too? I don't see these functions safeguarded for secondary replicas.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see these functions safeguarded for secondary replicas.

In which case we probably don't need to.

@anmolnaranmolnar left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm. Please address @wchevreuil 's comment.

@Kota-SHKota-SH left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kgeiszkgeisz left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@anmolnar
anmolnar merged commit 365f16e into apache:HBASE-29081Oct 27, 2025
1 check failed
anmolnar pushed a commit that referenced this pull request Mar 13, 2026
…filelist is n… (#7361)
* HBASE-29611: With FILE based SFT, the list of HFiles we maintain in .filelist is not getting updated for read replica
Link to JIRA: https://issues.apache.org/jira/browse/HBASE-29611
Description:
Steps to Repro (For detailed steps, check JIRA):
- Create two clusters on the same storage location.
- Create table on active, then refresh meta on the read replica to get the table meta data updated.
- Add some rows and flush on the active cluster, do refresh_hfiles on the read replica and scan table.
- If you now again add the rows in the table on active and do refresh_hfiles then the rows added are not visible in the read replica.
Cause:
The refresh store file is a two step process:
1. Load the existing store file from the .filelist (choose the file with higher timestamp for loading)
2. refresh store file internals (clean up old/compacted files, replace store file in .filelist)
In the current scenario, what is happening is that for the first time read-replica is loading the list of Hfiles from the file in .filelist created by active cluster but then it is creating the new file with greater timestamp. Now we have two files in .filelist. On the subsequent flush from active the file in .filelist created by the active gets updated but the file created by read-replica is not. While loading in the refresh_hfiles as we take the file with higher timestamp the file created by read-replica for the first time gets loaded which does not have an updated list of hfiles.
Fix:
As we just wanted the file from active to be loaded anytime we perform refresh store files, we must not create a new file in the .filelist from the read-replica, in this way we will stop the timestamp mismatch.
NOTE:
Also we don't want to initialize the tracker file (StoreFileListFile.java:load()) from read-replica as we are not writing it hence we have added check for read only property in StoreFileTrackerBase.java:load()
* Make read only cluster to behave like secondary replica
anmolnar pushed a commit that referenced this pull request Apr 8, 2026
…filelist is n… (#7361)
* HBASE-29611: With FILE based SFT, the list of HFiles we maintain in .filelist is not getting updated for read replica
Link to JIRA: https://issues.apache.org/jira/browse/HBASE-29611
Description:
Steps to Repro (For detailed steps, check JIRA):
- Create two clusters on the same storage location.
- Create table on active, then refresh meta on the read replica to get the table meta data updated.
- Add some rows and flush on the active cluster, do refresh_hfiles on the read replica and scan table.
- If you now again add the rows in the table on active and do refresh_hfiles then the rows added are not visible in the read replica.
Cause:
The refresh store file is a two step process:
1. Load the existing store file from the .filelist (choose the file with higher timestamp for loading)
2. refresh store file internals (clean up old/compacted files, replace store file in .filelist)
In the current scenario, what is happening is that for the first time read-replica is loading the list of Hfiles from the file in .filelist created by active cluster but then it is creating the new file with greater timestamp. Now we have two files in .filelist. On the subsequent flush from active the file in .filelist created by the active gets updated but the file created by read-replica is not. While loading in the refresh_hfiles as we take the file with higher timestamp the file created by read-replica for the first time gets loaded which does not have an updated list of hfiles.
Fix:
As we just wanted the file from active to be loaded anytime we perform refresh store files, we must not create a new file in the .filelist from the read-replica, in this way we will stop the timestamp mismatch.
NOTE:
Also we don't want to initialize the tracker file (StoreFileListFile.java:load()) from read-replica as we are not writing it hence we have added check for read only property in StoreFileTrackerBase.java:load()
* Make read only cluster to behave like secondary replica
anmolnar pushed a commit that referenced this pull request Apr 10, 2026
…filelist is n… (#7361)
* HBASE-29611: With FILE based SFT, the list of HFiles we maintain in .filelist is not getting updated for read replica
Link to JIRA: https://issues.apache.org/jira/browse/HBASE-29611
Description:
Steps to Repro (For detailed steps, check JIRA):
- Create two clusters on the same storage location.
- Create table on active, then refresh meta on the read replica to get the table meta data updated.
- Add some rows and flush on the active cluster, do refresh_hfiles on the read replica and scan table.
- If you now again add the rows in the table on active and do refresh_hfiles then the rows added are not visible in the read replica.
Cause:
The refresh store file is a two step process:
1. Load the existing store file from the .filelist (choose the file with higher timestamp for loading)
2. refresh store file internals (clean up old/compacted files, replace store file in .filelist)
In the current scenario, what is happening is that for the first time read-replica is loading the list of Hfiles from the file in .filelist created by active cluster but then it is creating the new file with greater timestamp. Now we have two files in .filelist. On the subsequent flush from active the file in .filelist created by the active gets updated but the file created by read-replica is not. While loading in the refresh_hfiles as we take the file with higher timestamp the file created by read-replica for the first time gets loaded which does not have an updated list of hfiles.
Fix:
As we just wanted the file from active to be loaded anytime we perform refresh store files, we must not create a new file in the .filelist from the read-replica, in this way we will stop the timestamp mismatch.
NOTE:
Also we don't want to initialize the tracker file (StoreFileListFile.java:load()) from read-replica as we are not writing it hence we have added check for read only property in StoreFileTrackerBase.java:load()
* Make read only cluster to behave like secondary replica
anmolnar pushed a commit that referenced this pull request May 5, 2026
…filelist is n… (#7361)
* HBASE-29611: With FILE based SFT, the list of HFiles we maintain in .filelist is not getting updated for read replica
Link to JIRA: https://issues.apache.org/jira/browse/HBASE-29611
Description:
Steps to Repro (For detailed steps, check JIRA):
- Create two clusters on the same storage location.
- Create table on active, then refresh meta on the read replica to get the table meta data updated.
- Add some rows and flush on the active cluster, do refresh_hfiles on the read replica and scan table.
- If you now again add the rows in the table on active and do refresh_hfiles then the rows added are not visible in the read replica.
Cause:
The refresh store file is a two step process:
1. Load the existing store file from the .filelist (choose the file with higher timestamp for loading)
2. refresh store file internals (clean up old/compacted files, replace store file in .filelist)
In the current scenario, what is happening is that for the first time read-replica is loading the list of Hfiles from the file in .filelist created by active cluster but then it is creating the new file with greater timestamp. Now we have two files in .filelist. On the subsequent flush from active the file in .filelist created by the active gets updated but the file created by read-replica is not. While loading in the refresh_hfiles as we take the file with higher timestamp the file created by read-replica for the first time gets loaded which does not have an updated list of hfiles.
Fix:
As we just wanted the file from active to be loaded anytime we perform refresh store files, we must not create a new file in the .filelist from the read-replica, in this way we will stop the timestamp mismatch.
NOTE:
Also we don't want to initialize the tracker file (StoreFileListFile.java:load()) from read-replica as we are not writing it hence we have added check for read only property in StoreFileTrackerBase.java:load()
* Make read only cluster to behave like secondary replica
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@sharmaar12@Apache-HBase@anmolnar@wchevreuil@Kota-SH@kgeisz