[GitHub] [hbase] Apache-HBase commented on pull request #3489: HBASE-26087 JVM crash when displaying RPC params by MonitoredRPCHandler
Apache-HBase commented on pull request #3489: URL: https://github.com/apache/hbase/pull/3489#issuecomment-897407739 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 26s | Docker mode activated. | | -0 :warning: | yetus | 0m 4s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 36s | master passed | | +1 :green_heart: | compile | 1m 13s | master passed | | +1 :green_heart: | shadedjars | 8m 21s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 43s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 15s | the patch passed | | +1 :green_heart: | compile | 1m 10s | the patch passed | | +1 :green_heart: | javac | 1m 10s | the patch passed | | +1 :green_heart: | shadedjars | 8m 10s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 41s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 135m 37s | hbase-server in the patch passed. | | | | 167m 36s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3489/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3489 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 9fd1feb7882b 4.15.0-151-generic #157-Ubuntu SMP Fri Jul 9 23:07:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 5e8a269b1a | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3489/3/testReport/ | | Max. process+thread count | 3755 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3489/3/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] nyl3532016 commented on a change in pull request #3538: HBASE-26045 Master control the global throughtput of all compaction servers
nyl3532016 commented on a change in pull request #3538: URL: https://github.com/apache/hbase/pull/3538#discussion_r687452241 ## File path: hbase-client/src/main/java/org/apache/hadoop/hbase/client/Admin.java ## @@ -2256,6 +2256,17 @@ void cloneTableSchema(TableName tableName, TableName newTableName, boolean prese */ boolean isCompactionOffloadEnabled() throws IOException; + /** + * update compaction server total throughput bound + * @param upperBound the total throughput upper bound of all compaction servers Review comment: This method talk to master only, compaction servers get throughput control message through periodic heartbeat report -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3499: HBASE-26089 Support RegionCoprocessor on CompactionServer
Apache-HBase commented on pull request #3499: URL: https://github.com/apache/hbase/pull/3499#issuecomment-897424215 -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3499: HBASE-26089 Support RegionCoprocessor on CompactionServer
Apache-HBase commented on pull request #3499: URL: https://github.com/apache/hbase/pull/3499#issuecomment-897424402 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 0s | Docker mode activated. | | -1 :x: | patch | 0m 6s | https://github.com/apache/hbase/pull/3499 does not apply to HBASE-25714. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help. | | Subsystem | Report/Notes | |--:|:-| | GITHUB PR | https://github.com/apache/hbase/pull/3499 | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3499/5/console | | versions | git=2.17.1 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] nyl3532016 closed pull request #3499: HBASE-26089 Support RegionCoprocessor on CompactionServer
nyl3532016 closed pull request #3499: URL: https://github.com/apache/hbase/pull/3499 -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (HBASE-26193) Do not store meta region location on zookeeper
[ https://issues.apache.org/jira/browse/HBASE-26193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17397916#comment-17397916 ] Duo Zhang commented on HBASE-26193: --- Design doc attached. PTAL [~stack]. Thanks. > Do not store meta region location on zookeeper > -- > > Key: HBASE-26193 > URL: https://issues.apache.org/jira/browse/HBASE-26193 > Project: HBase > Issue Type: Improvement > Components: meta, Zookeeper >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > > As it breaks one of our design rules > https://hbase.apache.org/book.html#design.invariants.zk.data > We used to think hbase should be recovered automatically when all the data on > zk (except the replication data) are cleared, but obviously, if you clear the > meta region location, the cluster will be in trouble, and need to use > operation tools to recover the cluster. > So here, along with the ConnectionRegistry improvements, we should also > consider move the meta region location off zookeeper. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HBASE-26185) Fix TestMaster#testMoveRegionWhenNotInitialized with hbase.min.version.move.system.tables
[
https://issues.apache.org/jira/browse/HBASE-26185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani reassigned HBASE-26185:
Assignee: Rushabh Shah (was: Viraj Jasani)
> Fix TestMaster#testMoveRegionWhenNotInitialized with
> hbase.min.version.move.system.tables
> -
>
> Key: HBASE-26185
> URL: https://issues.apache.org/jira/browse/HBASE-26185
> Project: HBase
> Issue Type: Test
>Reporter: Viraj Jasani
>Assignee: Rushabh Shah
>Priority: Minor
> Fix For: 2.5.0, 3.0.0-alpha-2, 1.7.2, 2.4.6, 2.3.7
>
>
> In order to protect meta region movement unexpectedly during upgrade with
> rsGroup enabled, it is good practice to keep
> hbase.min.version.move.system.tables in hbase-default for specific branch so
> that the use-case for the specific version of HBase is well under control.
> However, TestMaster#testMoveRegionWhenNotInitialized would fail because it
> would not find server to move meta to. We should fix this.
>
> {code:java}
> INFO [Time-limited test] master.HMaster(2029): Passed destination servername
> is null/empty so choosing a server at random
> java.lang.UnsupportedOperationExceptionjava.lang.UnsupportedOperationException
> at java.util.AbstractList.add(AbstractList.java:148) at
> java.util.AbstractList.add(AbstractList.java:108) at
> org.apache.hadoop.hbase.master.HMaster.move(HMaster.java:2031) at
> org.apache.hadoop.hbase.master.TestMaster.testMoveRegionWhenNotInitialized(TestMaster.java:181)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [hbase] virajjasani commented on a change in pull request #3407: HBASE-26018 Perf improvement in L1 cache - Optimistic call to buffer.retain()
virajjasani commented on a change in pull request #3407:
URL: https://github.com/apache/hbase/pull/3407#discussion_r687501045
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruAdaptiveBlockCache.java
##
@@ -646,14 +639,16 @@ private long updateSizeMetrics(LruCachedBlock cb, boolean
evict) {
@Override
public Cacheable getBlock(BlockCacheKey cacheKey, boolean caching, boolean
repeat,
boolean updateCacheMetrics) {
-LruCachedBlock cb = map.computeIfPresent(cacheKey, (key, val) -> {
- // It will be referenced by RPC path, so increase here. NOTICE: Must do
the retain inside
- // this block. because if retain outside the map#computeIfPresent, the
evictBlock may remove
- // the block and release, then we're retaining a block with refCnt=0
which is disallowed.
- // see HBASE-22422.
- val.getBuffer().retain();
- return val;
-});
+LruCachedBlock cb = map.get(cacheKey);
+if (cb != null) {
+ try {
+cb.getBuffer().retain();
Review comment:
> A cached buffer item detached from the cache still needs to have its
#release called w/ refcount at zero so the backing memory gets readded to the
pool.
Yeah I think this makes sense. Let me get back to this in case I find some
better and obvious way to improve perf and get some YCSB results.
--
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: issues-unsubscr...@hbase.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [hbase] virajjasani closed pull request #3407: HBASE-26018 Perf improvement in L1 cache - Optimistic call to buffer.retain()
virajjasani closed pull request #3407: URL: https://github.com/apache/hbase/pull/3407 -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (HBASE-26018) Perf improvement in L1 cache
[ https://issues.apache.org/jira/browse/HBASE-26018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viraj Jasani updated HBASE-26018: - Fix Version/s: (was: 3.0.0-alpha-2) (was: 2.5.0) > Perf improvement in L1 cache > > > Key: HBASE-26018 > URL: https://issues.apache.org/jira/browse/HBASE-26018 > Project: HBase > Issue Type: Improvement >Affects Versions: 3.0.0-alpha-1, 2.3.5, 2.4.4 >Reporter: Viraj Jasani >Assignee: Viraj Jasani >Priority: Major > Attachments: computeIfPresent.png > > > After HBASE-25698 is in, all L1 caching strategies perform buffer.retain() in > order to maintain refCount atomically while retrieving cached blocks > (CHM#computeIfPresent). Retaining refCount is coming up bit expensive in > terms of performance. Using computeIfPresent API, CHM uses coarse grained > segment locking and even if our computation is not so complex (we just call > block retain API), it will block other update APIs for the keys within bucket > that is locked. computeIfPresent keeps showing up on flame graphs as well > (attached one of them). Specifically when we see aggressive cache hits for > meta blocks (with major blocks in cache), we would want to get away from > coarse grained locking. > One of the suggestions came up while reviewing PR#3215 is to treat cache read > API as optimistic read and deal with block retain based refCount issues by > catching the respective Exception and let it treat as cache miss. This should > allow us to go ahead with lockless get API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-26018) Perf improvement in L1 cache
[ https://issues.apache.org/jira/browse/HBASE-26018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viraj Jasani updated HBASE-26018: - Resolution: Won't Fix Status: Resolved (was: Patch Available) Will get back to this if I can find a better way to deal with this improvement. Closing for now. > Perf improvement in L1 cache > > > Key: HBASE-26018 > URL: https://issues.apache.org/jira/browse/HBASE-26018 > Project: HBase > Issue Type: Improvement >Affects Versions: 3.0.0-alpha-1, 2.3.5, 2.4.4 >Reporter: Viraj Jasani >Assignee: Viraj Jasani >Priority: Major > Attachments: computeIfPresent.png > > > After HBASE-25698 is in, all L1 caching strategies perform buffer.retain() in > order to maintain refCount atomically while retrieving cached blocks > (CHM#computeIfPresent). Retaining refCount is coming up bit expensive in > terms of performance. Using computeIfPresent API, CHM uses coarse grained > segment locking and even if our computation is not so complex (we just call > block retain API), it will block other update APIs for the keys within bucket > that is locked. computeIfPresent keeps showing up on flame graphs as well > (attached one of them). Specifically when we see aggressive cache hits for > meta blocks (with major blocks in cache), we would want to get away from > coarse grained locking. > One of the suggestions came up while reviewing PR#3215 is to treat cache read > API as optimistic read and deal with block retain based refCount issues by > catching the respective Exception and let it treat as cache miss. This should > allow us to go ahead with lockless get API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [hbase] Apache-HBase commented on pull request #3489: HBASE-26087 JVM crash when displaying RPC params by MonitoredRPCHandler
Apache-HBase commented on pull request #3489: URL: https://github.com/apache/hbase/pull/3489#issuecomment-897451791 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 16s | Docker mode activated. | | -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 27s | master passed | | +1 :green_heart: | compile | 1m 4s | master passed | | +1 :green_heart: | shadedjars | 9m 3s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 39s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 7s | the patch passed | | +1 :green_heart: | compile | 1m 2s | the patch passed | | +1 :green_heart: | javac | 1m 2s | the patch passed | | +1 :green_heart: | shadedjars | 9m 3s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 37s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 209m 5s | hbase-server in the patch passed. | | | | 242m 18s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3489/3/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3489 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux fb10a513dc97 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 5e8a269b1a | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3489/3/testReport/ | | Max. process+thread count | 2361 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3489/3/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3580: HBASE-26089 Support RegionCoprocessor on CompactionServer
Apache-HBase commented on pull request #3580: URL: https://github.com/apache/hbase/pull/3580#issuecomment-897462296 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 3s | Docker mode activated. | ||| _ Prechecks _ | | +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. | | +1 :green_heart: | hbaseanti | 0m 0s | Patch does not have any anti-patterns. | | +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. | ||| _ HBASE-25714 Compile Tests _ | | +1 :green_heart: | mvninstall | 3m 53s | HBASE-25714 passed | | +1 :green_heart: | compile | 3m 19s | HBASE-25714 passed | | +1 :green_heart: | checkstyle | 1m 11s | HBASE-25714 passed | | +1 :green_heart: | spotbugs | 2m 6s | HBASE-25714 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 3m 35s | the patch passed | | +1 :green_heart: | compile | 3m 15s | the patch passed | | +1 :green_heart: | javac | 3m 15s | the patch passed | | -0 :warning: | checkstyle | 1m 10s | hbase-server: The patch generated 14 new + 268 unchanged - 4 fixed = 282 total (was 272) | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +1 :green_heart: | hadoopcheck | 18m 7s | Patch does not cause any errors with Hadoop 3.1.2 3.2.1 3.3.0. | | +1 :green_heart: | spotbugs | 2m 14s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 16s | The patch does not generate ASF License warnings. | | | | 47m 59s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3580/1/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3580 | | Optional Tests | dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux 6b908dcb63ac 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | HBASE-25714 / 85f02919da | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | checkstyle | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3580/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt | | Max. process+thread count | 95 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3580/1/console | | versions | git=2.17.1 maven=3.6.3 spotbugs=4.2.2 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (HBASE-26185) Fix TestMaster#testMoveRegionWhenNotInitialized with hbase.min.version.move.system.tables
[
https://issues.apache.org/jira/browse/HBASE-26185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani resolved HBASE-26185.
--
Resolution: Fixed
> Fix TestMaster#testMoveRegionWhenNotInitialized with
> hbase.min.version.move.system.tables
> -
>
> Key: HBASE-26185
> URL: https://issues.apache.org/jira/browse/HBASE-26185
> Project: HBase
> Issue Type: Test
>Reporter: Viraj Jasani
>Assignee: Rushabh Shah
>Priority: Minor
> Fix For: 2.5.0, 3.0.0-alpha-2, 1.7.2, 2.4.6, 2.3.7
>
>
> In order to protect meta region movement unexpectedly during upgrade with
> rsGroup enabled, it is good practice to keep
> hbase.min.version.move.system.tables in hbase-default for specific branch so
> that the use-case for the specific version of HBase is well under control.
> However, TestMaster#testMoveRegionWhenNotInitialized would fail because it
> would not find server to move meta to. We should fix this.
>
> {code:java}
> INFO [Time-limited test] master.HMaster(2029): Passed destination servername
> is null/empty so choosing a server at random
> java.lang.UnsupportedOperationExceptionjava.lang.UnsupportedOperationException
> at java.util.AbstractList.add(AbstractList.java:148) at
> java.util.AbstractList.add(AbstractList.java:108) at
> org.apache.hadoop.hbase.master.HMaster.move(HMaster.java:2031) at
> org.apache.hadoop.hbase.master.TestMaster.testMoveRegionWhenNotInitialized(TestMaster.java:181)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [hbase] sunhelly merged pull request #3553: HBASE-26155 JVM crash when scan
sunhelly merged pull request #3553: URL: https://github.com/apache/hbase/pull/3553 -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] wchevreuil commented on pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
wchevreuil commented on pull request #3574: URL: https://github.com/apache/hbase/pull/3574#issuecomment-897477826 One thought I had now is that we probably need to back off CatalogJanitor from running whilst a split/merge is going on. As we are creating the dirs under table directory, I guess there's a risk CatalogJanitor wipe those dirs off before the proc reaches the point to add the region in meta. Let me check on this futher. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] wchevreuil edited a comment on pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
wchevreuil edited a comment on pull request #3574: URL: https://github.com/apache/hbase/pull/3574#issuecomment-897477826 One thought I had now is that we probably need to back off CatalogJanitor from running whilst a split/merge is going on. As we are creating the dirs under table directory, I guess there's a risk CatalogJanitor wipe those dirs off before the proc reaches the point to add the region in meta. Let me check on this further. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] ddupg merged pull request #3477: HBASE-26084 Add owner of replication queue for ReplicationQueueInfo
ddupg merged pull request #3477: URL: https://github.com/apache/hbase/pull/3477 -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache9 commented on pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
Apache9 commented on pull request #3574: URL: https://github.com/apache/hbase/pull/3574#issuecomment-897480236 > One thought I had now is that we probably need to back off CatalogJanitor from running whilst a split/merge is going on. As we are creating the dirs under table directory, I guess there's a risk CatalogJanitor wipe those dirs off before the proc reaches the point to add the region in meta. Let me check on this further. Ah, yes, I also noticed this when review this PR as you mentioned CatalogJanitor. But even we do not write directly to region dir, there could still be an interval between we move the region into place and add it in meta table? I guess we should have already found the way to deal with this, otherwise it could cause data loss... -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (HBASE-26084) Add owner of replication queue for ReplicationQueueInfo
[ https://issues.apache.org/jira/browse/HBASE-26084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sun Xin resolved HBASE-26084. - Fix Version/s: 3.0.0-alpha-2 Resolution: Done Merged. Thank [~stack] [~zhangduo] for reviewing. > Add owner of replication queue for ReplicationQueueInfo > --- > > Key: HBASE-26084 > URL: https://issues.apache.org/jira/browse/HBASE-26084 > Project: HBase > Issue Type: Sub-task >Affects Versions: 3.0.0-alpha-1 >Reporter: Sun Xin >Assignee: Sun Xin >Priority: Major > Fix For: 3.0.0-alpha-2 > > > The current ReplicationQueueInfo only has queueId, which is not enough to > distinguish queues in ReplicationServer, so we need to add the RS holding > the queue for ReplicationQueueInfo. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-26155) JVM crash when scan
[
https://issues.apache.org/jira/browse/HBASE-26155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaolin Ha resolved HBASE-26155.
Fix Version/s: 3.0.0-alpha-1
2.3.7
2.4.6
2.5.0
Resolution: Fixed
Merged to master and branch2.3+, thanks [~stack] [~zhangduo] for reviewing.
> JVM crash when scan
> ---
>
> Key: HBASE-26155
> URL: https://issues.apache.org/jira/browse/HBASE-26155
> Project: HBase
> Issue Type: Bug
> Components: Scanners
>Affects Versions: 3.0.0-alpha-1
>Reporter: Xiaolin Ha
>Assignee: Xiaolin Ha
>Priority: Major
> Fix For: 2.5.0, 2.4.6, 2.3.7, 3.0.0-alpha-1
>
> Attachments: scan-error.png
>
>
> There are scanner close caused regionserver JVM coredump problems on our
> production clusters.
> {code:java}
> Stack: [0x7fca4b0cc000,0x7fca4b1cd000], sp=0x7fca4b1cb0d8, free
> space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V [libjvm.so+0x7fd314]
> J 2810 sun.misc.Unsafe.copyMemory(Ljava/lang/Object;JLjava/lang/Object;JJ)V
> (0 bytes) @ 0x7fdae55a9e61 [0x7fdae55a9d80+0xe1]
> j
> org.apache.hadoop.hbase.util.UnsafeAccess.unsafeCopy(Ljava/lang/Object;JLjava/lang/Object;JJ)V+36
> j
> org.apache.hadoop.hbase.util.UnsafeAccess.copy(Ljava/nio/ByteBuffer;I[BII)V+69
> j
> org.apache.hadoop.hbase.util.ByteBufferUtils.copyFromBufferToArray([BLjava/nio/ByteBuffer;III)V+39
> j
> org.apache.hadoop.hbase.CellUtil.copyQualifierTo(Lorg/apache/hadoop/hbase/Cell;[BI)I+31
> j
> org.apache.hadoop.hbase.KeyValueUtil.appendKeyTo(Lorg/apache/hadoop/hbase/Cell;[BI)I+43
> J 14724 C2 org.apache.hadoop.hbase.regionserver.StoreScanner.shipped()V (51
> bytes) @ 0x7fdae6a298d0 [0x7fdae6a29780+0x150]
> J 21387 C2
> org.apache.hadoop.hbase.regionserver.RSRpcServices$RegionScannerShippedCallBack.run()V
> (53 bytes) @ 0x7fdae622bab8 [0x7fdae622acc0+0xdf8]
> J 26353 C2
> org.apache.hadoop.hbase.ipc.ServerCall.setResponse(Lorg/apache/hbase/thirdparty/com/google/protobuf/Message;Lorg/apache/hadoop/hbase/CellScanner;Ljava/lang/Throwable;Ljava/lang/String;)V
> (384 bytes) @ 0x7fdae7f139d8 [0x7fdae7f12980+0x1058]
> J 26226 C2 org.apache.hadoop.hbase.ipc.CallRunner.run()V (1554 bytes) @
> 0x7fdae959f68c [0x7fdae959e400+0x128c]
> J 19598% C2
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(Ljava/util/concurrent/BlockingQueue;Ljava/util/concurrent/atomic/AtomicInteger;)V
> (338 bytes) @ 0x7fdae81c54d4 [0x7fdae81c53e0+0xf4]
> {code}
> There are also scan rpc errors when coredump happens at the handler,
> !scan-error.png|width=585,height=235!
> I found some clue in the logs, that some blocks may be replaced when its
> nextBlockOnDiskSize less than the newly one in the method
>
> {code:java}
> public static boolean shouldReplaceExistingCacheBlock(BlockCache blockCache,
> BlockCacheKey cacheKey, Cacheable newBlock) {
> if (cacheKey.toString().indexOf(".") != -1) { // reference file
> LOG.warn("replace existing cached block, cache key is : " + cacheKey);
> return true;
> }
> Cacheable existingBlock = blockCache.getBlock(cacheKey, false, false,
> false);
> if (existingBlock == null) {
> return true;
> }
> try {
> int comparison = BlockCacheUtil.validateBlockAddition(existingBlock,
> newBlock, cacheKey);
> if (comparison < 0) {
> LOG.warn("Cached block contents differ by nextBlockOnDiskSize, the new
> block has "
> + "nextBlockOnDiskSize set. Caching new block.");
> return true;
> ..{code}
>
> And the block will be replaced if it is not in the RAMCache but in the
> BucketCache.
> When using
>
> {code:java}
> private void putIntoBackingMap(BlockCacheKey key, BucketEntry bucketEntry) {
> BucketEntry previousEntry = backingMap.put(key, bucketEntry);
> if (previousEntry != null && previousEntry != bucketEntry) {
> ReentrantReadWriteLock lock = offsetLock.getLock(previousEntry.offset());
> lock.writeLock().lock();
> try {
> blockEvicted(key, previousEntry, false);
> } finally {
> lock.writeLock().unlock();
> }
> }
> }
> {code}
> to replace the old block, to avoid previous bucket entry mem leak, the
> previous bucket entry will be force released regardless of RPC references to
> it.
>
> {code:java}
> void blockEvicted(BlockCacheKey cacheKey, BucketEntry bucketEntry, boolean
> decrementBlockNumber) {
> bucketAllocator.freeBlock(bucketEntry.offset());
> realCacheSize.add(-1 * bucketEntry.getLength());
> blocksByHFile.remove(cacheKey);
> if (decrementBlockNumber) {
> this.blockNumber.decrement();
> }
> }
> {code}
> I used the check of RPC reference before replace bucket entry, and it works,
> no coredumps until now.
>
>
[GitHub] [hbase] Apache-HBase commented on pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
Apache-HBase commented on pull request #3574: URL: https://github.com/apache/hbase/pull/3574#issuecomment-897507937 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 8s | Docker mode activated. | ||| _ Prechecks _ | | +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. | | +1 :green_heart: | hbaseanti | 0m 0s | Patch does not have any anti-patterns. | | +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 22s | master passed | | +1 :green_heart: | compile | 3m 27s | master passed | | +1 :green_heart: | checkstyle | 1m 13s | master passed | | +1 :green_heart: | spotbugs | 2m 17s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 6s | the patch passed | | +1 :green_heart: | compile | 3m 25s | the patch passed | | +1 :green_heart: | javac | 3m 25s | the patch passed | | -0 :warning: | checkstyle | 1m 12s | hbase-server: The patch generated 10 new + 190 unchanged - 4 fixed = 200 total (was 194) | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +1 :green_heart: | hadoopcheck | 20m 41s | Patch does not cause any errors with Hadoop 3.1.2 3.2.1 3.3.0. | | +1 :green_heart: | spotbugs | 2m 23s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 13s | The patch does not generate ASF License warnings. | | | | 52m 53s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/2/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3574 | | Optional Tests | dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux 78cc9fb96dfa 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 238c9b40bf | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | checkstyle | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/2/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt | | Max. process+thread count | 86 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/2/console | | versions | git=2.17.1 maven=3.6.3 spotbugs=4.2.2 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache9 commented on pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
Apache9 commented on pull request #3574: URL: https://github.com/apache/hbase/pull/3574#issuecomment-897519279 After reviewing the code for CatalogJanitor, I do not think it will clean the partial regions on FileSystem, as I haven't seen any related code about scanning the table directory on FileSystem, it just scans the meta table. So in general, I think we should change the rollback code in SplitTableRegionProcedure and MergeTableRegionsProcedure, to remove the paritial regions when rolling back. And I think we should also have a tool in HBCK2 to remove the partial regions. Thanks. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (HBASE-26026) HBase Write may be stuck forever when using CompactingMemStore
[
https://issues.apache.org/jira/browse/HBASE-26026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26026:
-
Description:
Sometimes I observed that HBase Write might be stuck in my hbase cluster which
enabling {{CompactingMemStore}}. I have simulated the problem by unit test in
my PR.
The problem is caused by {{CompactingMemStore.checkAndAddToActiveSize}} :
{code:java}
425 private boolean checkAndAddToActiveSize(MutableSegment currActive, Cell
cellToAdd,
426 MemStoreSizing memstoreSizing) {
427if (shouldFlushInMemory(currActive, cellToAdd, memstoreSizing)) {
428 if (currActive.setInMemoryFlushed()) {
429flushInMemory(currActive);
430if (setInMemoryCompactionFlag()) {
431 // The thread is dispatched to do in-memory compaction in the
background
..
}
{code}
In line 427, {{shouldFlushInMemory}} checking if {{currActive.getDataSize}}
adding the size of {{cellToAdd}} exceeds
{{CompactingMemStore.inmemoryFlushSize}},if true, then {{currActive}} should
be flushed, {{currActive.setInMemoryFlushed()}} is invoked in line 428 ：
{code:java}
public boolean setInMemoryFlushed() {
return flushed.compareAndSet(false, true);
}
{code}
After sucessfully set {{currActive.flushed}} to true, in above line 429
{{flushInMemory(currActive)}} invokes
{{CompactingMemStore.pushActiveToPipeline}} :
{code:java}
protected void pushActiveToPipeline(MutableSegment currActive) {
if (!currActive.isEmpty()) {
pipeline.pushHead(currActive);
resetActive();
}
}
{code}
In above {{CompactingMemStore.pushActiveToPipeline}} method , if the
{{currActive.cellSet}} is empty, then nothing is done. Due to concurrent
writes and because we first add cell size to {{currActive.getDataSize}} and
then actually add cell to {{currActive.cellSet}}, it is possible that
{{currActive.getDataSize}} could not accommodate {{cellToAdd}} but
{{currActive.cellSet}} is still empty if pending writes which not yet add cells
to {{currActive.cellSet}}.
So if the {{currActive.cellSet}} is empty now, then no {{ActiveSegment}} is
created, and new writes still continue target to {{currActive}}, but
{{currActive.flushed}} is true, {{currActive}} could not enter
{{flushInMemory(currActive)}} again，and new {{ActiveSegment}} could not be
created forever ! In the end all writes would be stuck.
In my opinion , once {{currActive.flushed}} is set true, it could not continue
use as {{ActiveSegment}} , and because of concurrent pending writes, only after
{{currActive.updatesLock.writeLock()}} is acquired(i.e.
{{currActive.waitForUpdates}} is called) in
{{CompactingMemStore.inMemoryCompaction}} ,we can safely say {{currActive}} is
empty or not.
My fix is remove the {{if (!currActive.isEmpty())}} check here and left the
check to background {{InMemoryCompactionRunnable}} after
{{currActive.waitForUpdates}} is called. An alternative fix is we use
synchronization mechanism in {{checkAndAddToActiveSize}} method to prevent all
writes , wait for all pending write completed(i.e. currActive.waitForUpdates is
called) and if {{currActive}} is still empty ,then we set
{{currActive.flushed}} back to false,but I am not inclined to use so heavy
synchronization in write path, and I think we would better maintain lockless
implementation for {{CompactingMemStore.add}} method just as now and
{{currActive.waitForUpdates}} would better be left in background
{{InMemoryCompactionRunnable}}.
was:
Sometimes I observed that HBase Write might be stuck in my hbase cluster which
enabling {{CompactingMemStore}}. I have simulated the problem by unit test in
my PR.
The problem is caused by {{CompactingMemStore.checkAndAddToActiveSize}} :
{code:java}
425 private boolean checkAndAddToActiveSize(MutableSegment currActive, Cell
cellToAdd,
426 MemStoreSizing memstoreSizing) {
427if (shouldFlushInMemory(currActive, cellToAdd, memstoreSizing)) {
428 if (currActive.setInMemoryFlushed()) {
429flushInMemory(currActive);
430if (setInMemoryCompactionFlag()) {
431 // The thread is dispatched to do in-memory compaction in the
background
..
}
{code}
In line 427, if {{currActive.getDataSize}} adding the size of {{cellToAdd}}
exceeds {{CompactingMemStore.inmemoryFlushSize}}, then {{currActive}} should
be flushed, {{MutableSegment.setInMemoryFlushed()}} is invoked in above line
428 ：
{code:java}
public boolean setInMemoryFlushed() {
return flushed.compareAndSet(false, true);
}
{code}
After set {{currActive.flushed}} to true, in above line 429
{{flushInMemory(currActive)}} invokes
{{CompactingMemStore.pushActiveToPipeline}} :
{code:java}
protected void pushActiveToPipeline(MutableSegment currActive) {
if (!currActive.isEmpty()) {
pipeline.pushHead(currActive);
resetActive();
}
}
{code}
In above {{CompactingMemS
[jira] [Created] (HBASE-26194) Introduce a ReplicationServerSourceManager to simplify HReplicationServer
Sun Xin created HBASE-26194: --- Summary: Introduce a ReplicationServerSourceManager to simplify HReplicationServer Key: HBASE-26194 URL: https://issues.apache.org/jira/browse/HBASE-26194 Project: HBase Issue Type: Sub-task Components: Replication Affects Versions: 3.0.0-alpha-2 Reporter: Sun Xin Assignee: Sun Xin Fix For: 3.0.0-alpha-2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [hbase] Apache-HBase commented on pull request #3578: HBASE-25988 Store the store file list by a file
Apache-HBase commented on pull request #3578: URL: https://github.com/apache/hbase/pull/3578#issuecomment-897535763 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 58s | Docker mode activated. | ||| _ Prechecks _ | | +1 :green_heart: | dupname | 0m 1s | No case conflicting files found. | | +0 :ok: | prototool | 0m 1s | prototool was not available. | | +1 :green_heart: | hbaseanti | 0m 0s | Patch does not have any anti-patterns. | | +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. | ||| _ HBASE-26067 Compile Tests _ | | +0 :ok: | mvndep | 0m 14s | Maven dependency ordering for branch | | +1 :green_heart: | mvninstall | 4m 21s | HBASE-26067 passed | | +1 :green_heart: | compile | 4m 54s | HBASE-26067 passed | | +1 :green_heart: | checkstyle | 1m 19s | HBASE-26067 passed | | +1 :green_heart: | spotbugs | 6m 22s | HBASE-26067 passed | ||| _ Patch Compile Tests _ | | +0 :ok: | mvndep | 0m 11s | Maven dependency ordering for patch | | +1 :green_heart: | mvninstall | 4m 3s | the patch passed | | +1 :green_heart: | compile | 4m 53s | the patch passed | | +1 :green_heart: | cc | 4m 53s | the patch passed | | +1 :green_heart: | javac | 4m 53s | the patch passed | | +1 :green_heart: | checkstyle | 1m 17s | the patch passed | | -0 :warning: | whitespace | 0m 0s | The patch has 1 line(s) that end in whitespace. Use git apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply | | +1 :green_heart: | hadoopcheck | 20m 24s | Patch does not cause any errors with Hadoop 3.1.2 3.2.1 3.3.0. | | +1 :green_heart: | hbaseprotoc | 1m 42s | the patch passed | | +1 :green_heart: | spotbugs | 6m 48s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 23s | The patch does not generate ASF License warnings. | | | | 66m 35s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/2/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3578 | | Optional Tests | dupname asflicense cc hbaseprotoc prototool javac spotbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux 3105694b70d3 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | HBASE-26067 / 869c544daf | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | whitespace | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/2/artifact/yetus-general-check/output/whitespace-eol.txt | | Max. process+thread count | 86 (vs. ulimit of 3) | | modules | C: hbase-protocol-shaded hbase-server U: . | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/2/console | | versions | git=2.17.1 maven=3.6.3 spotbugs=4.2.2 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3580: HBASE-26089 Support RegionCoprocessor on CompactionServer
Apache-HBase commented on pull request #3580: URL: https://github.com/apache/hbase/pull/3580#issuecomment-897544429 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 3m 54s | Docker mode activated. | | -0 :warning: | yetus | 0m 5s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ HBASE-25714 Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 40s | HBASE-25714 passed | | +1 :green_heart: | compile | 1m 16s | HBASE-25714 passed | | +1 :green_heart: | shadedjars | 8m 10s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 44s | HBASE-25714 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 17s | the patch passed | | +1 :green_heart: | compile | 1m 14s | the patch passed | | +1 :green_heart: | javac | 1m 14s | the patch passed | | +1 :green_heart: | shadedjars | 8m 3s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 43s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 143m 11s | hbase-server in the patch passed. | | | | 178m 24s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3580/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3580 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 88b70316b40d 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | HBASE-25714 / 85f02919da | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3580/1/testReport/ | | Max. process+thread count | 4389 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3580/1/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3580: HBASE-26089 Support RegionCoprocessor on CompactionServer
Apache-HBase commented on pull request #3580: URL: https://github.com/apache/hbase/pull/3580#issuecomment-897555985 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 2m 38s | Docker mode activated. | | -0 :warning: | yetus | 0m 6s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ HBASE-25714 Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 49s | HBASE-25714 passed | | +1 :green_heart: | compile | 1m 18s | HBASE-25714 passed | | +1 :green_heart: | shadedjars | 9m 59s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 50s | HBASE-25714 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 51s | the patch passed | | +1 :green_heart: | compile | 1m 15s | the patch passed | | +1 :green_heart: | javac | 1m 15s | the patch passed | | +1 :green_heart: | shadedjars | 9m 56s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 42s | the patch passed | ||| _ Other Tests _ | | -1 :x: | unit | 157m 48s | hbase-server in the patch failed. | | | | 196m 44s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3580/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3580 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 91da3b9e504e 4.15.0-65-generic #74-Ubuntu SMP Tue Sep 17 17:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | HBASE-25714 / 85f02919da | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | unit | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3580/1/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3580/1/testReport/ | | Max. process+thread count | 3866 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3580/1/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
Apache-HBase commented on pull request #3574: URL: https://github.com/apache/hbase/pull/3574#issuecomment-897578019 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 27s | Docker mode activated. | | -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 33s | master passed | | +1 :green_heart: | compile | 1m 11s | master passed | | +1 :green_heart: | shadedjars | 8m 19s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 44s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 21s | the patch passed | | +1 :green_heart: | compile | 1m 12s | the patch passed | | +1 :green_heart: | javac | 1m 12s | the patch passed | | +1 :green_heart: | shadedjars | 8m 16s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 40s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 134m 50s | hbase-server in the patch passed. | | | | 167m 0s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3574 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux d99d1303660b 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 238c9b40bf | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/2/testReport/ | | Max. process+thread count | 3862 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/2/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] wchevreuil commented on pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
wchevreuil commented on pull request #3574: URL: https://github.com/apache/hbase/pull/3574#issuecomment-897583443 > After reviewing the code for CatalogJanitor, I do not think it will clean the partial regions on FileSystem, as I haven't seen any related code about scanning the table directory on FileSystem, it just scans the meta table. > > So in general, I think we should change the rollback code in SplitTableRegionProcedure and MergeTableRegionsProcedure, to remove the paritial regions when rolling back. > > And I think we should also have a tool in HBCK2 to remove the partial regions. > > Thanks. Yep, had just found the same. Had added the cleanup logic on the rollback. I will work on hbck2 on a separate issue. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache9 commented on a change in pull request #3468: HBASE-26076 Support favoredNodes when do compaction offload
Apache9 commented on a change in pull request #3468:
URL: https://github.com/apache/hbase/pull/3468#discussion_r687706580
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
##
@@ -344,14 +344,27 @@ private StoreContext
initializeStoreContext(ColumnFamilyDescriptor family) throw
}
private InetSocketAddress[] getFavoredNodes() {
-InetSocketAddress[] favoredNodes = null;
Review comment:
Does the code still compile after you remove this line? This is a
behavior change? We have a favoredNodes class field in HStore?
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
##
@@ -344,14 +344,27 @@ private StoreContext
initializeStoreContext(ColumnFamilyDescriptor family) throw
}
private InetSocketAddress[] getFavoredNodes() {
-InetSocketAddress[] favoredNodes = null;
if (region.getRegionServerServices() != null) {
- favoredNodes = region.getRegionServerServices().getFavoredNodesForRegion(
- region.getRegionInfo().getEncodedName());
+ return region.getRegionServerServices()
+ .getFavoredNodesForRegion(region.getRegionInfo().getEncodedName());
}
return favoredNodes;
}
+ // Favored nodes used by compaction offload
+ private InetSocketAddress[] favoredNodes = null;
+
+ public void setFavoredNodes(
+
List
favoredNodes) {
Review comment:
Just use HBaseProtos.ServerName?
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/compactionserver/CompactionThreadManager.java
##
@@ -150,6 +150,27 @@ public void requestCompaction(CompactionTask
compactionTask) throws IOException
}
}
+ /**
+ * Open store, and clean stale compacted file in cache
+ */
+ private HStore openStore(RegionInfo regionInfo, ColumnFamilyDescriptor cfd,
boolean major,
Review comment:
Is this related to this issue or just a refactoring?
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
##
@@ -344,14 +344,27 @@ private StoreContext
initializeStoreContext(ColumnFamilyDescriptor family) throw
}
private InetSocketAddress[] getFavoredNodes() {
-InetSocketAddress[] favoredNodes = null;
if (region.getRegionServerServices() != null) {
- favoredNodes = region.getRegionServerServices().getFavoredNodesForRegion(
- region.getRegionInfo().getEncodedName());
+ return region.getRegionServerServices()
+ .getFavoredNodesForRegion(region.getRegionInfo().getEncodedName());
}
return favoredNodes;
}
+ // Favored nodes used by compaction offload
+ private InetSocketAddress[] favoredNodes = null;
+
+ public void setFavoredNodes(
+
List
favoredNodes) {
+if (favoredNodes != null && favoredNodes.size() > 0) {
Review comment:
CollectionUtils.isNotEmpty?
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
##
@@ -344,14 +344,27 @@ private StoreContext
initializeStoreContext(ColumnFamilyDescriptor family) throw
}
private InetSocketAddress[] getFavoredNodes() {
-InetSocketAddress[] favoredNodes = null;
if (region.getRegionServerServices() != null) {
- favoredNodes = region.getRegionServerServices().getFavoredNodesForRegion(
- region.getRegionInfo().getEncodedName());
+ return region.getRegionServerServices()
+ .getFavoredNodesForRegion(region.getRegionInfo().getEncodedName());
}
return favoredNodes;
}
+ // Favored nodes used by compaction offload
+ private InetSocketAddress[] favoredNodes = null;
Review comment:
OK we added a class field here... It is calculated by a public method?
Will call be called multiple times? Thread safe?
--
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: issues-unsubscr...@hbase.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
Apache-HBase commented on pull request #3574: URL: https://github.com/apache/hbase/pull/3574#issuecomment-897644924 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 4s | Docker mode activated. | | -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 4s | master passed | | +1 :green_heart: | compile | 1m 2s | master passed | | +1 :green_heart: | shadedjars | 8m 55s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 38s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 8s | the patch passed | | +1 :green_heart: | compile | 1m 3s | the patch passed | | +1 :green_heart: | javac | 1m 3s | the patch passed | | +1 :green_heart: | shadedjars | 8m 59s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 38s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 234m 18s | hbase-server in the patch passed. | | | | 266m 52s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3574 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 4a96cd9806c9 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 238c9b40bf | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/2/testReport/ | | Max. process+thread count | 2646 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/2/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3578: HBASE-25988 Store the store file list by a file
Apache-HBase commented on pull request #3578: URL: https://github.com/apache/hbase/pull/3578#issuecomment-897651976 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 0s | Docker mode activated. | | -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ HBASE-26067 Compile Tests _ | | +0 :ok: | mvndep | 0m 14s | Maven dependency ordering for branch | | +1 :green_heart: | mvninstall | 5m 3s | HBASE-26067 passed | | +1 :green_heart: | compile | 2m 21s | HBASE-26067 passed | | +1 :green_heart: | shadedjars | 9m 11s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 56s | HBASE-26067 passed | ||| _ Patch Compile Tests _ | | +0 :ok: | mvndep | 0m 14s | Maven dependency ordering for patch | | +1 :green_heart: | mvninstall | 4m 50s | the patch passed | | +1 :green_heart: | compile | 2m 23s | the patch passed | | +1 :green_heart: | javac | 2m 23s | the patch passed | | +1 :green_heart: | shadedjars | 9m 5s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 54s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 1m 4s | hbase-protocol-shaded in the patch passed. | | +1 :green_heart: | unit | 205m 53s | hbase-server in the patch passed. | | | | 245m 18s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3578 | | Optional Tests | unit javac javadoc shadedjars compile | | uname | Linux e9d0ec84bf99 4.15.0-143-generic #147-Ubuntu SMP Wed Apr 14 16:10:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | HBASE-26067 / 869c544daf | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/2/testReport/ | | Max. process+thread count | 3061 (vs. ulimit of 3) | | modules | C: hbase-protocol-shaded hbase-server U: . | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/2/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] sunhelly commented on a change in pull request #3489: HBASE-26087 JVM crash when displaying RPC params by MonitoredRPCHandler
sunhelly commented on a change in pull request #3489:
URL: https://github.com/apache/hbase/pull/3489#discussion_r687732620
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/monitoring/MonitoredRPCHandlerImpl.java
##
@@ -53,11 +53,20 @@ public MonitoredRPCHandlerImpl() {
@Override
public synchronized MonitoredRPCHandlerImpl clone() {
-return (MonitoredRPCHandlerImpl) super.clone();
+MonitoredRPCHandlerImpl clone = (MonitoredRPCHandlerImpl) super.clone();
Review comment:
Hi, @saintstack , in addition to the call info map, I also add a boolean
variant to mark if the MonitoredRPCHandlerImpl is a cloned snapshot of the
handler level MonitoredRPCHandlerImpl. So when the UI requests to display the
call info map after clone the MonitoredRPCHandlerImpl, every request will has
its own snapshot of the MonitoredRPCHandlerImpl according to the request time.
And the non-snapshot MonitoredRPCHandlerImpl can generate its own call info map
which independent with all the snapshots. Thanks.
--
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: issues-unsubscr...@hbase.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [hbase] Apache9 commented on pull request #3580: HBASE-26089 Support RegionCoprocessor on CompactionServer
Apache9 commented on pull request #3580: URL: https://github.com/apache/hbase/pull/3580#issuecomment-897667710 I still have some questions about the design. Let's discuss more on the design doc. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache9 commented on a change in pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
Apache9 commented on a change in pull request #3574: URL: https://github.com/apache/hbase/pull/3574#discussion_r687752070 ## File path: hbase-server/src/main/java/org/apache/hadoop/hbase/master/assignment/SplitTableRegionProcedure.java ## @@ -648,9 +656,11 @@ public void createDaughterRegions(final MasterProcedureEnv env) throws IOExcepti // there's files to split. It then fires up everything, waits for // completion and finally checks for any exception // -// Note: splitStoreFiles creates daughter region dirs under the parent splits dir -// Nothing to unroll here if failure -- re-run createSplitsDir will -// clean this up. +// Note: From HBASE-26187, splitStoreFiles now creates daughter region dirs straight under the Review comment: The comment is incorrect now? We do not rely on CatalogJanitor to clean up the partial regions. We need to clean in rollback. I think we should just recreate the whole region directly when we call this method? -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3578: HBASE-25988 Store the store file list by a file
Apache-HBase commented on pull request #3578: URL: https://github.com/apache/hbase/pull/3578#issuecomment-897681894 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 20s | Docker mode activated. | | -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ HBASE-26067 Compile Tests _ | | +0 :ok: | mvndep | 0m 26s | Maven dependency ordering for branch | | +1 :green_heart: | mvninstall | 4m 50s | HBASE-26067 passed | | +1 :green_heart: | compile | 2m 14s | HBASE-26067 passed | | +1 :green_heart: | shadedjars | 10m 39s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 57s | HBASE-26067 passed | ||| _ Patch Compile Tests _ | | +0 :ok: | mvndep | 0m 17s | Maven dependency ordering for patch | | +1 :green_heart: | mvninstall | 4m 45s | the patch passed | | +1 :green_heart: | compile | 2m 13s | the patch passed | | +1 :green_heart: | javac | 2m 13s | the patch passed | | +1 :green_heart: | shadedjars | 10m 29s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 56s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 0m 55s | hbase-protocol-shaded in the patch passed. | | +1 :green_heart: | unit | 240m 26s | hbase-server in the patch passed. | | | | 282m 42s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3578 | | Optional Tests | unit javac javadoc shadedjars compile | | uname | Linux c8bb2eba25af 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | HBASE-26067 / 869c544daf | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/2/testReport/ | | Max. process+thread count | 2641 (vs. ulimit of 3) | | modules | C: hbase-protocol-shaded hbase-server U: . | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/2/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
Apache-HBase commented on pull request #3574: URL: https://github.com/apache/hbase/pull/3574#issuecomment-897688686 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 6s | Docker mode activated. | ||| _ Prechecks _ | | +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. | | +1 :green_heart: | hbaseanti | 0m 0s | Patch does not have any anti-patterns. | | +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 13s | master passed | | +1 :green_heart: | compile | 3m 27s | master passed | | +1 :green_heart: | checkstyle | 1m 13s | master passed | | +1 :green_heart: | spotbugs | 2m 15s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 4s | the patch passed | | +1 :green_heart: | compile | 3m 20s | the patch passed | | +1 :green_heart: | javac | 3m 20s | the patch passed | | -0 :warning: | checkstyle | 1m 13s | hbase-server: The patch generated 10 new + 190 unchanged - 4 fixed = 200 total (was 194) | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +1 :green_heart: | hadoopcheck | 20m 19s | Patch does not cause any errors with Hadoop 3.1.2 3.2.1 3.3.0. | | +1 :green_heart: | spotbugs | 2m 41s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 11s | The patch does not generate ASF License warnings. | | | | 52m 45s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/3/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3574 | | Optional Tests | dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux 9ea0a3d87b79 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 238c9b40bf | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | checkstyle | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/3/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt | | Max. process+thread count | 85 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/3/console | | versions | git=2.17.1 maven=3.6.3 spotbugs=4.2.2 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache9 merged pull request #3421: HBASE-26026 HBase Write may be stuck forever when using CompactingMem…
Apache9 merged pull request #3421: URL: https://github.com/apache/hbase/pull/3421 -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (HBASE-26026) HBase Write may be stuck forever when using CompactingMemStore
[
https://issues.apache.org/jira/browse/HBASE-26026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang updated HBASE-26026:
--
Hadoop Flags: Reviewed
Resolution: Fixed
Status: Resolved (was: Patch Available)
Pushed to branch-2.3+.
Thanks [~comnetwork] for contributing.
> HBase Write may be stuck forever when using CompactingMemStore
> --
>
> Key: HBASE-26026
> URL: https://issues.apache.org/jira/browse/HBASE-26026
> Project: HBase
> Issue Type: Bug
> Components: in-memory-compaction
>Affects Versions: 3.0.0-alpha-1, 2.3.0, 2.4.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Critical
> Fix For: 2.5.0, 3.0.0-alpha-2, 2.4.6, 2.3.7
>
>
> Sometimes I observed that HBase Write might be stuck in my hbase cluster
> which enabling {{CompactingMemStore}}. I have simulated the problem by unit
> test in my PR.
> The problem is caused by {{CompactingMemStore.checkAndAddToActiveSize}} :
> {code:java}
> 425 private boolean checkAndAddToActiveSize(MutableSegment currActive, Cell
> cellToAdd,
> 426 MemStoreSizing memstoreSizing) {
> 427if (shouldFlushInMemory(currActive, cellToAdd, memstoreSizing)) {
> 428 if (currActive.setInMemoryFlushed()) {
> 429flushInMemory(currActive);
> 430if (setInMemoryCompactionFlag()) {
> 431 // The thread is dispatched to do in-memory compaction in the
> background
> ..
> }
> {code}
> In line 427, {{shouldFlushInMemory}} checking if {{currActive.getDataSize}}
> adding the size of {{cellToAdd}} exceeds
> {{CompactingMemStore.inmemoryFlushSize}},if true, then {{currActive}}
> should be flushed, {{currActive.setInMemoryFlushed()}} is invoked in line
> 428 ：
> {code:java}
> public boolean setInMemoryFlushed() {
> return flushed.compareAndSet(false, true);
> }
> {code}
> After sucessfully set {{currActive.flushed}} to true, in above line 429
> {{flushInMemory(currActive)}} invokes
> {{CompactingMemStore.pushActiveToPipeline}} :
> {code:java}
> protected void pushActiveToPipeline(MutableSegment currActive) {
> if (!currActive.isEmpty()) {
> pipeline.pushHead(currActive);
> resetActive();
> }
> }
> {code}
> In above {{CompactingMemStore.pushActiveToPipeline}} method , if the
> {{currActive.cellSet}} is empty, then nothing is done. Due to concurrent
> writes and because we first add cell size to {{currActive.getDataSize}} and
> then actually add cell to {{currActive.cellSet}}, it is possible that
> {{currActive.getDataSize}} could not accommodate {{cellToAdd}} but
> {{currActive.cellSet}} is still empty if pending writes which not yet add
> cells to {{currActive.cellSet}}.
> So if the {{currActive.cellSet}} is empty now, then no {{ActiveSegment}} is
> created, and new writes still continue target to {{currActive}}, but
> {{currActive.flushed}} is true, {{currActive}} could not enter
> {{flushInMemory(currActive)}} again，and new {{ActiveSegment}} could not be
> created forever ! In the end all writes would be stuck.
> In my opinion , once {{currActive.flushed}} is set true, it could not
> continue use as {{ActiveSegment}} , and because of concurrent pending writes,
> only after {{currActive.updatesLock.writeLock()}} is acquired(i.e.
> {{currActive.waitForUpdates}} is called) in
> {{CompactingMemStore.inMemoryCompaction}} ,we can safely say {{currActive}}
> is empty or not.
> My fix is remove the {{if (!currActive.isEmpty())}} check here and left the
> check to background {{InMemoryCompactionRunnable}} after
> {{currActive.waitForUpdates}} is called. An alternative fix is we use
> synchronization mechanism in {{checkAndAddToActiveSize}} method to prevent
> all writes , wait for all pending write completed(i.e.
> currActive.waitForUpdates is called) and if {{currActive}} is still empty
> ,then we set {{currActive.flushed}} back to false,but I am not inclined to
> use so heavy synchronization in write path, and I think we would better
> maintain lockless implementation for {{CompactingMemStore.add}} method just
> as now and {{currActive.waitForUpdates}} would better be left in background
> {{InMemoryCompactionRunnable}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [hbase] wchevreuil commented on a change in pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
wchevreuil commented on a change in pull request #3574: URL: https://github.com/apache/hbase/pull/3574#discussion_r687844530 ## File path: hbase-server/src/main/java/org/apache/hadoop/hbase/master/assignment/SplitTableRegionProcedure.java ## @@ -648,9 +656,11 @@ public void createDaughterRegions(final MasterProcedureEnv env) throws IOExcepti // there's files to split. It then fires up everything, waits for // completion and finally checks for any exception // -// Note: splitStoreFiles creates daughter region dirs under the parent splits dir -// Nothing to unroll here if failure -- re-run createSplitsDir will -// clean this up. +// Note: From HBASE-26187, splitStoreFiles now creates daughter region dirs straight under the Review comment: Yeah, let me remove the CatalogJanitor mention. >I think we should just recreate the whole region directly when we call this method? Like, first we check if the given daughter region dir already exists and if so, delete it? -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache9 commented on a change in pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
Apache9 commented on a change in pull request #3574: URL: https://github.com/apache/hbase/pull/3574#discussion_r687847994 ## File path: hbase-server/src/main/java/org/apache/hadoop/hbase/master/assignment/SplitTableRegionProcedure.java ## @@ -648,9 +656,11 @@ public void createDaughterRegions(final MasterProcedureEnv env) throws IOExcepti // there's files to split. It then fires up everything, waits for // completion and finally checks for any exception // -// Note: splitStoreFiles creates daughter region dirs under the parent splits dir -// Nothing to unroll here if failure -- re-run createSplitsDir will -// clean this up. +// Note: From HBASE-26187, splitStoreFiles now creates daughter region dirs straight under the Review comment: I suppose so. Unless we could make sure that every time we will generate the reference files with the same name, then we could just create the reference file with overwrite = true. Otherwise I think we'd better clean the directory and recreate it... -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3578: HBASE-25988 Store the store file list by a file
Apache-HBase commented on pull request #3578: URL: https://github.com/apache/hbase/pull/3578#issuecomment-897746600 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 45s | Docker mode activated. | ||| _ Prechecks _ | | +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. | | +0 :ok: | prototool | 0m 0s | prototool was not available. | | +1 :green_heart: | hbaseanti | 0m 0s | Patch does not have any anti-patterns. | | +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. | ||| _ HBASE-26067 Compile Tests _ | | +0 :ok: | mvndep | 0m 17s | Maven dependency ordering for branch | | +1 :green_heart: | mvninstall | 5m 3s | HBASE-26067 passed | | +1 :green_heart: | compile | 5m 22s | HBASE-26067 passed | | +1 :green_heart: | checkstyle | 1m 28s | HBASE-26067 passed | | +1 :green_heart: | spotbugs | 7m 47s | HBASE-26067 passed | ||| _ Patch Compile Tests _ | | +0 :ok: | mvndep | 0m 14s | Maven dependency ordering for patch | | +1 :green_heart: | mvninstall | 4m 50s | the patch passed | | +1 :green_heart: | compile | 6m 9s | the patch passed | | +1 :green_heart: | cc | 6m 9s | the patch passed | | +1 :green_heart: | javac | 6m 9s | the patch passed | | +1 :green_heart: | checkstyle | 1m 34s | the patch passed | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +1 :green_heart: | hadoopcheck | 23m 47s | Patch does not cause any errors with Hadoop 3.1.2 3.2.1 3.3.0. | | +1 :green_heart: | hbaseprotoc | 1m 58s | the patch passed | | +1 :green_heart: | spotbugs | 8m 6s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 26s | The patch does not generate ASF License warnings. | | | | 78m 44s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/3/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3578 | | Optional Tests | dupname asflicense cc hbaseprotoc prototool javac spotbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux 12bccab08fd8 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | HBASE-26067 / 869c544daf | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Max. process+thread count | 86 (vs. ulimit of 3) | | modules | C: hbase-protocol-shaded hbase-server U: . | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/3/console | | versions | git=2.17.1 maven=3.6.3 spotbugs=4.2.2 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (HBASE-26185) Fix TestMaster#testMoveRegionWhenNotInitialized with hbase.min.version.move.system.tables
[
https://issues.apache.org/jira/browse/HBASE-26185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398140#comment-17398140
]
Hudson commented on HBASE-26185:
Results for branch branch-1
[build #159 on
builds.a.o|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-1/159/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-1/159//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk7 checks{color}
-- For more information [see jdk7
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-1/159//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-1/159//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Fix TestMaster#testMoveRegionWhenNotInitialized with
> hbase.min.version.move.system.tables
> -
>
> Key: HBASE-26185
> URL: https://issues.apache.org/jira/browse/HBASE-26185
> Project: HBase
> Issue Type: Test
>Reporter: Viraj Jasani
>Assignee: Rushabh Shah
>Priority: Minor
> Fix For: 2.5.0, 3.0.0-alpha-2, 1.7.2, 2.4.6, 2.3.7
>
>
> In order to protect meta region movement unexpectedly during upgrade with
> rsGroup enabled, it is good practice to keep
> hbase.min.version.move.system.tables in hbase-default for specific branch so
> that the use-case for the specific version of HBase is well under control.
> However, TestMaster#testMoveRegionWhenNotInitialized would fail because it
> would not find server to move meta to. We should fix this.
>
> {code:java}
> INFO [Time-limited test] master.HMaster(2029): Passed destination servername
> is null/empty so choosing a server at random
> java.lang.UnsupportedOperationExceptionjava.lang.UnsupportedOperationException
> at java.util.AbstractList.add(AbstractList.java:148) at
> java.util.AbstractList.add(AbstractList.java:108) at
> org.apache.hadoop.hbase.master.HMaster.move(HMaster.java:2031) at
> org.apache.hadoop.hbase.master.TestMaster.testMoveRegionWhenNotInitialized(TestMaster.java:181)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [hbase] Apache-HBase commented on pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
Apache-HBase commented on pull request #3574: URL: https://github.com/apache/hbase/pull/3574#issuecomment-897780559 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 28s | Docker mode activated. | | -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 15s | master passed | | +1 :green_heart: | compile | 1m 13s | master passed | | +1 :green_heart: | shadedjars | 8m 13s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 40s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 15s | the patch passed | | +1 :green_heart: | compile | 1m 14s | the patch passed | | +1 :green_heart: | javac | 1m 14s | the patch passed | | +1 :green_heart: | shadedjars | 8m 4s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 41s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 134m 39s | hbase-server in the patch passed. | | | | 166m 4s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3574 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 1c0c3ba70237 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 238c9b40bf | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/3/testReport/ | | Max. process+thread count | 3837 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/3/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3489: HBASE-26087 JVM crash when displaying RPC params by MonitoredRPCHandler
Apache-HBase commented on pull request #3489: URL: https://github.com/apache/hbase/pull/3489#issuecomment-897786455 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 27s | Docker mode activated. | | -0 :warning: | yetus | 0m 4s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 14s | master passed | | +1 :green_heart: | compile | 1m 11s | master passed | | +1 :green_heart: | shadedjars | 8m 9s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 40s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 19s | the patch passed | | +1 :green_heart: | compile | 1m 14s | the patch passed | | +1 :green_heart: | javac | 1m 14s | the patch passed | | +1 :green_heart: | shadedjars | 8m 10s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 40s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 135m 42s | hbase-server in the patch passed. | | | | 167m 8s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3489/4/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3489 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 8d3d6079aad2 4.15.0-151-generic #157-Ubuntu SMP Fri Jul 9 23:07:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 238c9b40bf | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3489/4/testReport/ | | Max. process+thread count | 3737 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3489/4/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3489: HBASE-26087 JVM crash when displaying RPC params by MonitoredRPCHandler
Apache-HBase commented on pull request #3489: URL: https://github.com/apache/hbase/pull/3489#issuecomment-897796201 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 3s | Docker mode activated. | | -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 1s | master passed | | +1 :green_heart: | compile | 1m 1s | master passed | | +1 :green_heart: | shadedjars | 8m 11s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 38s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 3m 44s | the patch passed | | +1 :green_heart: | compile | 1m 2s | the patch passed | | +1 :green_heart: | javac | 1m 2s | the patch passed | | +1 :green_heart: | shadedjars | 8m 18s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 39s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 150m 32s | hbase-server in the patch passed. | | | | 181m 34s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3489/4/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3489 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux e1d694b00958 4.15.0-65-generic #74-Ubuntu SMP Tue Sep 17 17:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 238c9b40bf | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3489/4/testReport/ | | Max. process+thread count | 3661 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3489/4/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (HBASE-26195) Data is present in replicated cluster but not visible on primary cluster.
Rushabh Shah created HBASE-26195:
Summary: Data is present in replicated cluster but not visible on
primary cluster.
Key: HBASE-26195
URL: https://issues.apache.org/jira/browse/HBASE-26195
Project: HBase
Issue Type: Bug
Components: Replication, wal
Affects Versions: 1.7.0
Reporter: Rushabh Shah
Assignee: Rushabh Shah
We encountered a case where we are seeing some rows (via Phoenix) in replicated
cluster but they are not present in source/active cluster.
Triaging further we found memstore rollback logs in few of the region servers.
{noformat}
2021-07-28 14:17:59,353 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
rollbackMemstore rolled back 23
2021-07-28 14:17:59,353 DEBUG [,queue=25,port=60020] regionserver.HRegion -
rollbackMemstore rolled back 23
2021-07-28 14:17:59,354 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
rollbackMemstore rolled back 23
2021-07-28 14:17:59,354 DEBUG [,queue=25,port=60020] regionserver.HRegion -
rollbackMemstore rolled back 23
2021-07-28 14:17:59,354 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
rollbackMemstore rolled back 23
2021-07-28 14:17:59,354 DEBUG [,queue=25,port=60020] regionserver.HRegion -
rollbackMemstore rolled back 23
2021-07-28 14:17:59,355 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
rollbackMemstore rolled back 23
2021-07-28 14:17:59,355 DEBUG [,queue=25,port=60020] regionserver.HRegion -
rollbackMemstore rolled back 23
2021-07-28 14:17:59,356 DEBUG [,queue=25,port=60020] regionserver.HRegion -
rollbackMemstore rolled back 23
{noformat}
Looking more into logs, found that there were some hdfs layer issues sync'ing
wal to hdfs.
It was taking around 6 mins to sync wal. Logs below
{noformat}
2021-07-28 14:19:30,511 WARN [sync.0] hdfs.DataStreamer - Slow
waitForAckedSeqno took 391210ms (threshold=3ms). File being written:
/hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
pipeline datanodes:
[DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
2021-07-28 14:19:30,589 WARN [sync.1] hdfs.DataStreamer - Slow
waitForAckedSeqno took 391148ms (threshold=3ms). File being written:
/hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
pipeline datanodes:
[DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
2021-07-28 14:19:30,589 WARN [sync.2] hdfs.DataStreamer - Slow
waitForAckedSeqno took 391147ms (threshold=3ms). File being written:
/hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
pipeline datanodes:
[DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
2021-07-28 14:19:30,591 INFO [sync.0] wal.FSHLog - Slow sync cost: 391289 ms,
current pipeline:
[DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]]
2021-07-28 14:19:30,591 INFO [sync.1] wal.FSHLog - Slow sync cost: 391227 ms,
current pipeline:
[DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]]
2021-07-28 14:19:30,591 WARN [sync.1] wal.FSHLog - Requesting log roll because
we exceeded slow sync threshold; time=391227 ms, threshold=1 ms, current
pipeline:
[DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]]
2021-07-28 14:19:30,591 INFO [sync.2] wal.FSHLog - Slow sync cost: 391227 ms,
current pipeline:
[DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]]
2021-07-28 14:19:30,591 WARN [sync.2] wal.FSHLog - Requesting log roll because
we exceeded slow sync
[jira] [Updated] (HBASE-26195) Data is present in replicated cluster but not present in primary cluster.
[
https://issues.apache.org/jira/browse/HBASE-26195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rushabh Shah updated HBASE-26195:
-
Summary: Data is present in replicated cluster but not present in primary
cluster. (was: Data is present in replicated cluster but not visible on
primary cluster.)
> Data is present in replicated cluster but not present in primary cluster.
> -
>
> Key: HBASE-26195
> URL: https://issues.apache.org/jira/browse/HBASE-26195
> Project: HBase
> Issue Type: Bug
> Components: Replication, wal
>Affects Versions: 1.7.0
>Reporter: Rushabh Shah
>Assignee: Rushabh Shah
>Priority: Major
>
> We encountered a case where we are seeing some rows (via Phoenix) in
> replicated cluster but they are not present in source/active cluster.
> Triaging further we found memstore rollback logs in few of the region servers.
> {noformat}
> 2021-07-28 14:17:59,353 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,353 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,355 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,355 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,356 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> {noformat}
> Looking more into logs, found that there were some hdfs layer issues sync'ing
> wal to hdfs.
> It was taking around 6 mins to sync wal. Logs below
> {noformat}
> 2021-07-28 14:19:30,511 WARN [sync.0] hdfs.DataStreamer - Slow
> waitForAckedSeqno took 391210ms (threshold=3ms). File being written:
> /hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
> block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
> pipeline datanodes:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
> 2021-07-28 14:19:30,589 WARN [sync.1] hdfs.DataStreamer - Slow
> waitForAckedSeqno took 391148ms (threshold=3ms). File being written:
> /hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
> block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
> pipeline datanodes:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
> 2021-07-28 14:19:30,589 WARN [sync.2] hdfs.DataStreamer - Slow
> waitForAckedSeqno took 391147ms (threshold=3ms). File being written:
> /hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
> block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
> pipeline datanodes:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
> 2021-07-28 14:19:30,591 INFO [sync.0] wal.FSHLog - Slow sync cost: 391289
> ms, current pipeline:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]]
> 2021-07-28 14:19:30,591 INFO [sync.1] wal.FSHLog - Slow sync cost: 391227
> ms, current pipeline:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]]
> 2021-07-28 14:19:30,591 WARN [sync.1] wal.FSHLog - Requesting log roll
> because we exceeded slow sync threshold; time=391227 ms, threshold=1 ms,
> current pipeline:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b2
[GitHub] [hbase] apurtell commented on a change in pull request #3579: HBASE-26189 Reduce log level of CompactionProgress notice to DEBUG
apurtell commented on a change in pull request #3579:
URL: https://github.com/apache/hbase/pull/3579#discussion_r687931899
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/CompactionProgress.java
##
@@ -77,8 +77,10 @@ public void complete() {
*/
public long getTotalCompactingKVs() {
if (totalCompactingKVs < currentCompactedKVs) {
- LOG.warn("totalCompactingKVs={} less than currentCompactedKVs={}",
+ if (LOG.isDebugEnabled()) {
Review comment:
Sure, I'll remember that (and remove the 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.
To unsubscribe, e-mail: issues-unsubscr...@hbase.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (HBASE-26192) hbck.jsp should provide a JSON formatted output option
[
https://issues.apache.org/jira/browse/HBASE-26192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Kyle Purtell updated HBASE-26192:
Description:
It used to be possible to get hbck's verdict of cluster status from the command
line, especially useful for headless deployments, i.e. without requiring a
browser with sufficient connectivity to load a UI, or scrape information out of
raw HTML, or write regex to comb over log4j output. The hbck tool's output
wasn't particularly convenient to parse but it was straightforward to extract
the desired information with a handful of regular expressions.
HBCK2 has a different design philosophy than the old hbck, which is to serve as
a collection of small and discrete recovery and repair functions, rather than
attempt to be a universal repair tool. This makes a lot of sense and isn't the
issue at hand. Unfortunately the old hbck's utility for reporting the current
cluster health assessment has not been replaced either in whole or in part.
Instead:
{quote}
HBCK2 is for fixes. For listings of inconsistencies or blockages in the running
cluster, you go elsewhere, to the logs and UI of the running cluster Master.
Once an issue has been identified, you use the HBCK2 tool to ask the Master to
effect fixes or to skip-over bad state. Asking the Master to make the fixes
rather than try and effect the repair locally in a fix-it tool's context is
another important difference between HBCK2 and hbck1.
{quote}
Developing custom tooling to mine logs and scrape UI simply to gain a top level
assessment of system health is unsatisfying. There should be a convenient means
for querying the system if issues that rise to the level of _inconsistency_, in
the hbck parlance, are believed to be present. It would be relatively simple to
bring back the experience of invoking a command line tool to deliver a verdict.
This could be added to the hbck2 tool itself but given that
hbase-operator-tools is a separate project an intrinsic solution is desirable.
An option that immediately comes to mind is modification of the Master's
hbck.jsp page to provide a JSON formatted output option if the HTTP Accept
header asks for text/json. However, looking at the source of hbck.jsp, it makes
more sense to leave it as is and implement a convenient machine parseable
output format elsewhere. This can be trivially accomplished with a new servlet.
Like hbck.jsp the servlet implementation would get a reference to HbckChore and
present the information this class makes available via its various getters.
The machine parseable output is sufficient to enable headless hbck status
checking but it still would be nice if we could provide operators a command
line tool that formats the information for convenient viewing in a terminal.
That part could be implemented in the hbck2 tool after this proposal is
implemented.
was:
It used to be possible to get hbck's verdict of cluster status from the command
line, especially useful for headless deployments, i.e. without requiring a
browser with sufficient connectivity to load a UI, or scrape information out of
raw HTML, or write regex to comb over log4j output. The hbck tool's output
wasn't particularly convenient to parse but it was straightforward to extract
the desired information with a handful of regular expressions.
HBCK2 has a different design philosophy than the old hbck, which is to serve as
a collection of small and discrete recovery and repair functions, rather than
attempt to be a universal repair tool. This makes a lot of sense and isn't the
issue at hand. Unfortunately the old hbck's utility for reporting the current
cluster health assessment has not been replaced either in whole or in part.
Instead:
{quote}
HBCK2 is for fixes. For listings of inconsistencies or blockages in the running
cluster, you go elsewhere, to the logs and UI of the running cluster Master.
Once an issue has been identified, you use the HBCK2 tool to ask the Master to
effect fixes or to skip-over bad state. Asking the Master to make the fixes
rather than try and effect the repair locally in a fix-it tool's context is
another important difference between HBCK2 and hbck1.
{quote}
Developing custom tooling to mine logs and scrape UI simply to gain a top level
assessment of system health is unsatisfying. There should be a convenient means
for querying the system if issues that rise to the level of _inconsistency_, in
the hbck parlance, are believed to be present. It would be relatively simple to
bring back the experience of invoking a command line tool to deliver a verdict.
This could be added to the hbck2 tool itself but given that
hbase-operator-tools is a separate project an intrinsic solution is desirable.
An option that immediately comes to mind is modification of the Master's
hbck.jsp page to provide a JSON formatted output option if the HTTP Acce
[GitHub] [hbase] Apache-HBase commented on pull request #3578: HBASE-25988 Store the store file list by a file
Apache-HBase commented on pull request #3578: URL: https://github.com/apache/hbase/pull/3578#issuecomment-897820994 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 27s | Docker mode activated. | | -0 :warning: | yetus | 0m 4s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ HBASE-26067 Compile Tests _ | | +0 :ok: | mvndep | 0m 30s | Maven dependency ordering for branch | | +1 :green_heart: | mvninstall | 4m 15s | HBASE-26067 passed | | +1 :green_heart: | compile | 2m 8s | HBASE-26067 passed | | +1 :green_heart: | shadedjars | 8m 9s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 55s | HBASE-26067 passed | ||| _ Patch Compile Tests _ | | +0 :ok: | mvndep | 0m 17s | Maven dependency ordering for patch | | +1 :green_heart: | mvninstall | 4m 18s | the patch passed | | +1 :green_heart: | compile | 2m 9s | the patch passed | | +1 :green_heart: | javac | 2m 9s | the patch passed | | +1 :green_heart: | shadedjars | 8m 16s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 54s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 1m 0s | hbase-protocol-shaded in the patch passed. | | -1 :x: | unit | 141m 8s | hbase-server in the patch failed. | | | | 177m 2s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3578 | | Optional Tests | unit javac javadoc shadedjars compile | | uname | Linux d8bc99ce690c 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | HBASE-26067 / 869c544daf | | Default Java | AdoptOpenJDK-11.0.10+9 | | unit | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/3/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/3/testReport/ | | Max. process+thread count | 4172 (vs. ulimit of 3) | | modules | C: hbase-protocol-shaded hbase-server U: . | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/3/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] bharathv commented on a change in pull request #3566: HBASE-26172 Deprecated MasterRegistry and allow getBootstrapNodes to …
bharathv commented on a change in pull request #3566:
URL: https://github.com/apache/hbase/pull/3566#discussion_r687946455
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java
##
@@ -308,18 +310,35 @@
*/
private static final long
DEFAULT_REGION_SERVER_RPC_MINIMUM_SCAN_TIME_LIMIT_DELTA = 10;
- /*
+ /**
* Whether to reject rows with size > threshold defined by
* {@link RSRpcServices#BATCH_ROWS_THRESHOLD_NAME}
*/
private static final String REJECT_BATCH_ROWS_OVER_THRESHOLD =
"hbase.rpc.rows.size.threshold.reject";
- /*
+ /**
* Default value of config {@link
RSRpcServices#REJECT_BATCH_ROWS_OVER_THRESHOLD}
*/
private static final boolean DEFAULT_REJECT_BATCH_ROWS_OVER_THRESHOLD =
false;
+ /**
+ * Determine the bootstrap nodes we want to return to the client connection
registry.
+ *
+ * {@link #MASTER}: return masters as bootstrap nodes.
Review comment:
Ah ok. It appeared that you intended to keep both MasterRegistry,
RpcConnectionRegistry with masters. Misunderstanding.
> Maybe we should rename RpcConnectionRegistry to RegionServerRegistry, and
all the configuration names should be changed.
To me this sounds like something we should do, explicitly communicates that
we want RS to be the bootstrap points and master is no where. So +1 on this.
Not sure what others think or if they have a different preference. To me its ok
to not change the configuration names, but I'm also if you plan to change them.
> And the plan here is to deprecate MasterRegistry in 2.5.0, not 4.0.0, we
will remove it in 4.0.0...
Ya thats what I meant, typo
--
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: issues-unsubscr...@hbase.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (HBASE-26195) Data is present in replicated cluster but not present in primary cluster.
[
https://issues.apache.org/jira/browse/HBASE-26195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharath Vissapragada updated HBASE-26195:
-
Affects Version/s: 2.5.0
3.0.0-alpha-1
> Data is present in replicated cluster but not present in primary cluster.
> -
>
> Key: HBASE-26195
> URL: https://issues.apache.org/jira/browse/HBASE-26195
> Project: HBase
> Issue Type: Bug
> Components: Replication, wal
>Affects Versions: 3.0.0-alpha-1, 1.7.0, 2.5.0
>Reporter: Rushabh Shah
>Assignee: Rushabh Shah
>Priority: Major
>
> We encountered a case where we are seeing some rows (via Phoenix) in
> replicated cluster but they are not present in source/active cluster.
> Triaging further we found memstore rollback logs in few of the region servers.
> {noformat}
> 2021-07-28 14:17:59,353 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,353 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,355 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,355 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,356 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> {noformat}
> Looking more into logs, found that there were some hdfs layer issues sync'ing
> wal to hdfs.
> It was taking around 6 mins to sync wal. Logs below
> {noformat}
> 2021-07-28 14:19:30,511 WARN [sync.0] hdfs.DataStreamer - Slow
> waitForAckedSeqno took 391210ms (threshold=3ms). File being written:
> /hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
> block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
> pipeline datanodes:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
> 2021-07-28 14:19:30,589 WARN [sync.1] hdfs.DataStreamer - Slow
> waitForAckedSeqno took 391148ms (threshold=3ms). File being written:
> /hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
> block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
> pipeline datanodes:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
> 2021-07-28 14:19:30,589 WARN [sync.2] hdfs.DataStreamer - Slow
> waitForAckedSeqno took 391147ms (threshold=3ms). File being written:
> /hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
> block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
> pipeline datanodes:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
> 2021-07-28 14:19:30,591 INFO [sync.0] wal.FSHLog - Slow sync cost: 391289
> ms, current pipeline:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]]
> 2021-07-28 14:19:30,591 INFO [sync.1] wal.FSHLog - Slow sync cost: 391227
> ms, current pipeline:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]]
> 2021-07-28 14:19:30,591 WARN [sync.1] wal.FSHLog - Requesting log roll
> because we exceeded slow sync threshold; time=391227 ms, threshold=1 ms,
> current pipeline:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c58
[jira] [Commented] (HBASE-26185) Fix TestMaster#testMoveRegionWhenNotInitialized with hbase.min.version.move.system.tables
[
https://issues.apache.org/jira/browse/HBASE-26185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398198#comment-17398198
]
Hudson commented on HBASE-26185:
Results for branch branch-2.3
[build #273 on
builds.a.o|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.3/273/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.3/273/General_20Nightly_20Build_20Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.3/273/JDK8_20Nightly_20Build_20Report_20_28Hadoop2_29/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.3/273/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 jdk11 hadoop3 checks{color}
-- For more information [see jdk11
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.3/273/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}
> Fix TestMaster#testMoveRegionWhenNotInitialized with
> hbase.min.version.move.system.tables
> -
>
> Key: HBASE-26185
> URL: https://issues.apache.org/jira/browse/HBASE-26185
> Project: HBase
> Issue Type: Test
>Reporter: Viraj Jasani
>Assignee: Rushabh Shah
>Priority: Minor
> Fix For: 2.5.0, 3.0.0-alpha-2, 1.7.2, 2.4.6, 2.3.7
>
>
> In order to protect meta region movement unexpectedly during upgrade with
> rsGroup enabled, it is good practice to keep
> hbase.min.version.move.system.tables in hbase-default for specific branch so
> that the use-case for the specific version of HBase is well under control.
> However, TestMaster#testMoveRegionWhenNotInitialized would fail because it
> would not find server to move meta to. We should fix this.
>
> {code:java}
> INFO [Time-limited test] master.HMaster(2029): Passed destination servername
> is null/empty so choosing a server at random
> java.lang.UnsupportedOperationExceptionjava.lang.UnsupportedOperationException
> at java.util.AbstractList.add(AbstractList.java:148) at
> java.util.AbstractList.add(AbstractList.java:108) at
> org.apache.hadoop.hbase.master.HMaster.move(HMaster.java:2031) at
> org.apache.hadoop.hbase.master.TestMaster.testMoveRegionWhenNotInitialized(TestMaster.java:181)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [hbase] Apache-HBase commented on pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
Apache-HBase commented on pull request #3574: URL: https://github.com/apache/hbase/pull/3574#issuecomment-897833703 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 58s | Docker mode activated. | | -0 :warning: | yetus | 0m 2s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 23s | master passed | | +1 :green_heart: | compile | 1m 3s | master passed | | +1 :green_heart: | shadedjars | 9m 9s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 39s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 6s | the patch passed | | +1 :green_heart: | compile | 1m 5s | the patch passed | | +1 :green_heart: | javac | 1m 5s | the patch passed | | +1 :green_heart: | shadedjars | 9m 9s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 36s | the patch passed | ||| _ Other Tests _ | | -1 :x: | unit | 210m 41s | hbase-server in the patch failed. | | | | 243m 51s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/3/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3574 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux abe9229dd2e4 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 238c9b40bf | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | unit | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/3/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/3/testReport/ | | Max. process+thread count | 2806 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/3/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (HBASE-26185) Fix TestMaster#testMoveRegionWhenNotInitialized with hbase.min.version.move.system.tables
[
https://issues.apache.org/jira/browse/HBASE-26185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398222#comment-17398222
]
Hudson commented on HBASE-26185:
Results for branch branch-2
[build #321 on
builds.a.o|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/General_20Nightly_20Build_20Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/JDK8_20Nightly_20Build_20Report_20_28Hadoop2_29/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 jdk11 hadoop3 checks{color}
-- For more information [see jdk11
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/JDK11_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(x) {color:red}-1 client integration test{color}
-- Something went wrong with this stage, [check relevant console
output|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321//console].
> Fix TestMaster#testMoveRegionWhenNotInitialized with
> hbase.min.version.move.system.tables
> -
>
> Key: HBASE-26185
> URL: https://issues.apache.org/jira/browse/HBASE-26185
> Project: HBase
> Issue Type: Test
>Reporter: Viraj Jasani
>Assignee: Rushabh Shah
>Priority: Minor
> Fix For: 2.5.0, 3.0.0-alpha-2, 1.7.2, 2.4.6, 2.3.7
>
>
> In order to protect meta region movement unexpectedly during upgrade with
> rsGroup enabled, it is good practice to keep
> hbase.min.version.move.system.tables in hbase-default for specific branch so
> that the use-case for the specific version of HBase is well under control.
> However, TestMaster#testMoveRegionWhenNotInitialized would fail because it
> would not find server to move meta to. We should fix this.
>
> {code:java}
> INFO [Time-limited test] master.HMaster(2029): Passed destination servername
> is null/empty so choosing a server at random
> java.lang.UnsupportedOperationExceptionjava.lang.UnsupportedOperationException
> at java.util.AbstractList.add(AbstractList.java:148) at
> java.util.AbstractList.add(AbstractList.java:108) at
> org.apache.hadoop.hbase.master.HMaster.move(HMaster.java:2031) at
> org.apache.hadoop.hbase.master.TestMaster.testMoveRegionWhenNotInitialized(TestMaster.java:181)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-26122) Limit max result size of individual Gets
[
https://issues.apache.org/jira/browse/HBASE-26122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398221#comment-17398221
]
Hudson commented on HBASE-26122:
Results for branch branch-2
[build #321 on
builds.a.o|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/General_20Nightly_20Build_20Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/JDK8_20Nightly_20Build_20Report_20_28Hadoop2_29/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 jdk11 hadoop3 checks{color}
-- For more information [see jdk11
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/JDK11_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(x) {color:red}-1 client integration test{color}
-- Something went wrong with this stage, [check relevant console
output|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321//console].
> Limit max result size of individual Gets
>
>
> Key: HBASE-26122
> URL: https://issues.apache.org/jira/browse/HBASE-26122
> Project: HBase
> Issue Type: New Feature
> Components: Client, regionserver
>Reporter: Bryan Beaudreault
>Assignee: Bryan Beaudreault
>Priority: Major
> Fix For: 2.5.0, 3.0.0-alpha-2
>
>
> Scans have the ability to have a configured max result size, which causes
> them to return a partial result once the limit has been reached. MultiGets
> also can throw MultiActionResultTooLarge if the response size is over a
> configured quota. Neither of these really accounts for a single Get of a
> too-large row. Such too-large Gets can cause substantial GC pressure or worse
> if sent at volume.
> Currently one can work around this by converting their Get to a single row
> Scan, but this requires a developer to proactively know about and prepare for
> the issue by using a Scan upfront or wait for the RegionServer to choke on a
> large request and only then rewrite the Get for future requests.
> We should implement the same response size limits for for Get as for Scan,
> whereby the server returns a partial result to the client for handling.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-26155) JVM crash when scan
[
https://issues.apache.org/jira/browse/HBASE-26155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398223#comment-17398223
]
Hudson commented on HBASE-26155:
Results for branch branch-2
[build #321 on
builds.a.o|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/General_20Nightly_20Build_20Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/JDK8_20Nightly_20Build_20Report_20_28Hadoop2_29/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 jdk11 hadoop3 checks{color}
-- For more information [see jdk11
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321/JDK11_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(x) {color:red}-1 client integration test{color}
-- Something went wrong with this stage, [check relevant console
output|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2/321//console].
> JVM crash when scan
> ---
>
> Key: HBASE-26155
> URL: https://issues.apache.org/jira/browse/HBASE-26155
> Project: HBase
> Issue Type: Bug
> Components: Scanners
>Affects Versions: 3.0.0-alpha-1
>Reporter: Xiaolin Ha
>Assignee: Xiaolin Ha
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.6, 2.3.7
>
> Attachments: scan-error.png
>
>
> There are scanner close caused regionserver JVM coredump problems on our
> production clusters.
> {code:java}
> Stack: [0x7fca4b0cc000,0x7fca4b1cd000], sp=0x7fca4b1cb0d8, free
> space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V [libjvm.so+0x7fd314]
> J 2810 sun.misc.Unsafe.copyMemory(Ljava/lang/Object;JLjava/lang/Object;JJ)V
> (0 bytes) @ 0x7fdae55a9e61 [0x7fdae55a9d80+0xe1]
> j
> org.apache.hadoop.hbase.util.UnsafeAccess.unsafeCopy(Ljava/lang/Object;JLjava/lang/Object;JJ)V+36
> j
> org.apache.hadoop.hbase.util.UnsafeAccess.copy(Ljava/nio/ByteBuffer;I[BII)V+69
> j
> org.apache.hadoop.hbase.util.ByteBufferUtils.copyFromBufferToArray([BLjava/nio/ByteBuffer;III)V+39
> j
> org.apache.hadoop.hbase.CellUtil.copyQualifierTo(Lorg/apache/hadoop/hbase/Cell;[BI)I+31
> j
> org.apache.hadoop.hbase.KeyValueUtil.appendKeyTo(Lorg/apache/hadoop/hbase/Cell;[BI)I+43
> J 14724 C2 org.apache.hadoop.hbase.regionserver.StoreScanner.shipped()V (51
> bytes) @ 0x7fdae6a298d0 [0x7fdae6a29780+0x150]
> J 21387 C2
> org.apache.hadoop.hbase.regionserver.RSRpcServices$RegionScannerShippedCallBack.run()V
> (53 bytes) @ 0x7fdae622bab8 [0x7fdae622acc0+0xdf8]
> J 26353 C2
> org.apache.hadoop.hbase.ipc.ServerCall.setResponse(Lorg/apache/hbase/thirdparty/com/google/protobuf/Message;Lorg/apache/hadoop/hbase/CellScanner;Ljava/lang/Throwable;Ljava/lang/String;)V
> (384 bytes) @ 0x7fdae7f139d8 [0x7fdae7f12980+0x1058]
> J 26226 C2 org.apache.hadoop.hbase.ipc.CallRunner.run()V (1554 bytes) @
> 0x7fdae959f68c [0x7fdae959e400+0x128c]
> J 19598% C2
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(Ljava/util/concurrent/BlockingQueue;Ljava/util/concurrent/atomic/AtomicInteger;)V
> (338 bytes) @ 0x7fdae81c54d4 [0x7fdae81c53e0+0xf4]
> {code}
> There are also scan rpc errors when coredump happens at the handler,
> !scan-error.png|width=585,height=235!
> I found some clue in the logs, that some blocks may be replaced when its
> nextBlockOnDiskSize less than the newly one in the method
>
> {code:java}
> public static boolean shouldReplaceExistingCacheBlock(BlockCache blockCache,
> BlockCacheKey cacheKey, Cacheable newBlock) {
> if (cacheKey.toString().indexOf(".") != -1) { // reference file
> LOG.warn("replace existing cached block, cache key is : " + cacheKey);
> return true;
> }
> Cacheable existingBlock = blockCache.getBlock(cacheKey, false, false,
> false);
> if (existingBlock == null) {
> return true;
> }
> try {
> int comparison = BlockCacheUtil.validateBlockAddition(existingBlock,
> newBlock, cacheKey);
> if (comparison < 0) {
> LOG.warn("Cached block contents differ by nextBlockOnDiskSize, the new
> block has "
> + "nextBlockOnDiskSize set. Caching new block.");
> return true;
> ...
[GitHub] [hbase] Apache-HBase commented on pull request #3578: HBASE-25988 Store the store file list by a file
Apache-HBase commented on pull request #3578: URL: https://github.com/apache/hbase/pull/3578#issuecomment-897877708 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 6s | Docker mode activated. | | -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ HBASE-26067 Compile Tests _ | | +0 :ok: | mvndep | 0m 12s | Maven dependency ordering for branch | | +1 :green_heart: | mvninstall | 4m 4s | HBASE-26067 passed | | +1 :green_heart: | compile | 1m 48s | HBASE-26067 passed | | +1 :green_heart: | shadedjars | 9m 2s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 48s | HBASE-26067 passed | ||| _ Patch Compile Tests _ | | +0 :ok: | mvndep | 0m 13s | Maven dependency ordering for patch | | +1 :green_heart: | mvninstall | 4m 6s | the patch passed | | +1 :green_heart: | compile | 1m 50s | the patch passed | | +1 :green_heart: | javac | 1m 50s | the patch passed | | +1 :green_heart: | shadedjars | 9m 9s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 48s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 0m 48s | hbase-protocol-shaded in the patch passed. | | +1 :green_heart: | unit | 216m 53s | hbase-server in the patch passed. | | | | 252m 54s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/3/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3578 | | Optional Tests | unit javac javadoc shadedjars compile | | uname | Linux ea0a89ca2bb1 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | HBASE-26067 / 869c544daf | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/3/testReport/ | | Max. process+thread count | 3784 (vs. ulimit of 3) | | modules | C: hbase-protocol-shaded hbase-server U: . | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3578/3/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (HBASE-26195) Data is present in replicated cluster but not present in primary cluster.
[
https://issues.apache.org/jira/browse/HBASE-26195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398232#comment-17398232
]
Rushabh Shah commented on HBASE-26195:
--
We discussed the following solutions at my day job. Actually it was Bharath,
Andrew and Geoffrey so all the credit goes to them.
*Approach 1*: +Add a rollback marker in WAL after we rollback from Memstore.+
After we rollback mutation from memstore, we should add a rollback marker in
WAL with the same timestamp as the append timestamp. Setting the rollback
mutation timestamp same as the original timestamp is the key here otherwise we
will undo the edits happened between the timestamps.
This can cause some correctness issues until we have HBASE-25975. Without
HBASE-25975, in case of same timestamps, deletes takes precedence over put
mutations.
*Approach 2*: +Do not replicate entries (for currently active WAL) until
WALKey#log_sequence_number <= mvcc#readPoint.+
Today ReplicationSourceWALReaderThread don't have access to HRegion's MVCC
object but that can be made available.
Both the above approaches suffers from the same inconsistency in case of RS
crash.
Consider the following sequence of events.
Approach 1
1 syncFuture timed out
2 client notified of failure
3 sync succeeded in the background
4 memstore rollback
5 apply rollback marker in the WAL and replicate
if RS crashes between 4-5, row is present in peer cluster but not in source
cluster.
Approach 2
1 syncFuture timed out
2 client notified of failure
3 sync succeeded in the background
4 replication waiting until logSeq <= mvcc#readPoint
5 memstore rollback
6 RS crashes
Now this WAL replication is handled by another RS which has no mvcc state to
rely on, so the best can do is replicate, so we are in the same problem again.
*Approach 3:* +Just abort the regionserver instead of doing Memstore Rollback.+
In this approach, client will be notified of the failure but on the server
side, the mutation succeeds and the mutation will be replicated to peer cluster
also.
This way both the source and peer cluster will be in consistent state.
Cons of Approach 3: If we start aborting RS in case of _not-very-grave_ HDFS
issues, then we will lose hbase capacity quickly and cluster will be in
unavailable state.
Given that we don't have append-and-sync atomic op in hdfs, there will be edge
cases whichever solution we choose.
[~bharathv] [~apurtell] [~gjacoby] Please correct me if I missed anything.
> Data is present in replicated cluster but not present in primary cluster.
> -
>
> Key: HBASE-26195
> URL: https://issues.apache.org/jira/browse/HBASE-26195
> Project: HBase
> Issue Type: Bug
> Components: Replication, wal
>Affects Versions: 3.0.0-alpha-1, 1.7.0, 2.5.0
>Reporter: Rushabh Shah
>Assignee: Rushabh Shah
>Priority: Major
>
> We encountered a case where we are seeing some rows (via Phoenix) in
> replicated cluster but they are not present in source/active cluster.
> Triaging further we found memstore rollback logs in few of the region servers.
> {noformat}
> 2021-07-28 14:17:59,353 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,353 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,355 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,355 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,356 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> {noformat}
> Looking more into logs, found that there were some hdfs layer issues sync'ing
> wal to hdfs.
> It was taking around 6 mins to sync wal. Logs below
> {noformat}
> 2021-07-28 14:19:30,511 WARN [sync.0] hdfs.DataStreamer - Slow
> waitForAckedSeqno took 391210ms (threshold=3ms). File being written:
> /hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
> block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
> pipeline datanodes:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeIn
[GitHub] [hbase] taklwu merged pull request #3561: HBASE-26128 Backport HBASE-25454 "Add trace support for connection re…
taklwu merged pull request #3561: URL: https://github.com/apache/hbase/pull/3561 -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] wchevreuil commented on a change in pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
wchevreuil commented on a change in pull request #3574: URL: https://github.com/apache/hbase/pull/3574#discussion_r688079612 ## File path: hbase-server/src/main/java/org/apache/hadoop/hbase/master/assignment/SplitTableRegionProcedure.java ## @@ -648,9 +656,11 @@ public void createDaughterRegions(final MasterProcedureEnv env) throws IOExcepti // there's files to split. It then fires up everything, waits for // completion and finally checks for any exception // -// Note: splitStoreFiles creates daughter region dirs under the parent splits dir -// Nothing to unroll here if failure -- re-run createSplitsDir will -// clean this up. +// Note: From HBASE-26187, splitStoreFiles now creates daughter region dirs straight under the Review comment: Ok, added extra check on HRegionFileSystem.createSplitsDir to delete the daughter regions if those already exist. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (HBASE-26193) Do not store meta region location on zookeeper
[ https://issues.apache.org/jira/browse/HBASE-26193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398288#comment-17398288 ] Michael Stack commented on HBASE-26193: --- +1 on your suggestion of keeping meta location in master-local-region w/ the master publishing to zk on restart. > Do not store meta region location on zookeeper > -- > > Key: HBASE-26193 > URL: https://issues.apache.org/jira/browse/HBASE-26193 > Project: HBase > Issue Type: Improvement > Components: meta, Zookeeper >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > > As it breaks one of our design rules > https://hbase.apache.org/book.html#design.invariants.zk.data > We used to think hbase should be recovered automatically when all the data on > zk (except the replication data) are cleared, but obviously, if you clear the > meta region location, the cluster will be in trouble, and need to use > operation tools to recover the cluster. > So here, along with the ConnectionRegistry improvements, we should also > consider move the meta region location off zookeeper. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (HBASE-26193) Do not store meta region location on zookeeper
[ https://issues.apache.org/jira/browse/HBASE-26193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398288#comment-17398288 ] Michael Stack edited comment on HBASE-26193 at 8/12/21, 9:02 PM: - +1 on your suggestion of keeping meta location in master-local-region w/ the master publishing to zk on restart. Thanks for looking into this. (FYI [~zyork] ) was (Author: stack): +1 on your suggestion of keeping meta location in master-local-region w/ the master publishing to zk on restart. > Do not store meta region location on zookeeper > -- > > Key: HBASE-26193 > URL: https://issues.apache.org/jira/browse/HBASE-26193 > Project: HBase > Issue Type: Improvement > Components: meta, Zookeeper >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > > As it breaks one of our design rules > https://hbase.apache.org/book.html#design.invariants.zk.data > We used to think hbase should be recovered automatically when all the data on > zk (except the replication data) are cleared, but obviously, if you clear the > meta region location, the cluster will be in trouble, and need to use > operation tools to recover the cluster. > So here, along with the ConnectionRegistry improvements, we should also > consider move the meta region location off zookeeper. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26195) Data is present in replicated cluster but not present in primary cluster.
[
https://issues.apache.org/jira/browse/HBASE-26195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398291#comment-17398291
]
Geoffrey Jacoby commented on HBASE-26195:
-
[~shahrs87] Personally I'd lean toward Approach 3, since this is a rare
condition and I don't expect it to affect availability much. However it would
be good to be configurable so that use cases that value availability over
absolute consistency can disable the abort logic.
> Data is present in replicated cluster but not present in primary cluster.
> -
>
> Key: HBASE-26195
> URL: https://issues.apache.org/jira/browse/HBASE-26195
> Project: HBase
> Issue Type: Bug
> Components: Replication, wal
>Affects Versions: 3.0.0-alpha-1, 1.7.0, 2.5.0
>Reporter: Rushabh Shah
>Assignee: Rushabh Shah
>Priority: Major
>
> We encountered a case where we are seeing some rows (via Phoenix) in
> replicated cluster but they are not present in source/active cluster.
> Triaging further we found memstore rollback logs in few of the region servers.
> {noformat}
> 2021-07-28 14:17:59,353 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,353 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,355 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,355 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,356 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> {noformat}
> Looking more into logs, found that there were some hdfs layer issues sync'ing
> wal to hdfs.
> It was taking around 6 mins to sync wal. Logs below
> {noformat}
> 2021-07-28 14:19:30,511 WARN [sync.0] hdfs.DataStreamer - Slow
> waitForAckedSeqno took 391210ms (threshold=3ms). File being written:
> /hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
> block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
> pipeline datanodes:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
> 2021-07-28 14:19:30,589 WARN [sync.1] hdfs.DataStreamer - Slow
> waitForAckedSeqno took 391148ms (threshold=3ms). File being written:
> /hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
> block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
> pipeline datanodes:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
> 2021-07-28 14:19:30,589 WARN [sync.2] hdfs.DataStreamer - Slow
> waitForAckedSeqno took 391147ms (threshold=3ms). File being written:
> /hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
> block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
> pipeline datanodes:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
> 2021-07-28 14:19:30,591 INFO [sync.0] wal.FSHLog - Slow sync cost: 391289
> ms, current pipeline:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]]
> 2021-07-28 14:19:30,591 INFO [sync.1] wal.FSHLog - Slow sync cost: 391227
> ms, current pipeline:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]]
> 2021-07-28 14:19:30,591 WARN [sync.1] wal.FSHLog - Requesting log roll
> because we exceeded slow sync threshold; time=39
[jira] [Commented] (HBASE-26186) "Packaging and Integration" stage broken on branch-2 since 8bc180c7737bbd1792851004625c552896bf57c6
[
https://issues.apache.org/jira/browse/HBASE-26186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398300#comment-17398300
]
Sean Busbey commented on HBASE-26186:
-
To confirm the failure, this is how I found the relevant workspace:
* Go to the [build page for a failed build (not blue
ocean)|https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/320/]
* click on ["pipeline
steps"|https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/320/flowGraphTable/]
in the left hand nav area
* scroll way down to the [shell script that failed in the packaging and
integration
work|https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/320/execution/node/191/]
* the top of that page lists the parent pipeline steps. click on them until you
get to the [step that allocated a
node|https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/320/execution/node/3/].
* that page links to the [workspace for the executor on the
host|https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/320/execution/node/3/ws/]
* at the time there was a hadoop-3.1.1 tarball that was ~3 MB. downloading and
using it locally it showed the same failure as the job.
Another way to do this is to go the [failed job's list of all workspaces
used|https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/320/ws/]
(left nav bar from the job page) and just spot check for the file we knew was
messed up. In this case there were only 6. this approach also makes it clearer
that this workspace was on the {{hbase9}} node.
Previously I would have clicked the "clear workspace" link on the workspace
link to wipe everything for that executor on that host. But that link is no
longer present. I reached out to #asfinfra on slack and they ssh'd to the
machine and removed the file.
> "Packaging and Integration" stage broken on branch-2 since
> 8bc180c7737bbd1792851004625c552896bf57c6
> ---
>
> Key: HBASE-26186
> URL: https://issues.apache.org/jira/browse/HBASE-26186
> Project: HBase
> Issue Type: Task
> Components: build, integration tests
>Affects Versions: 2.5.0
>Reporter: Nick Dimiduk
>Priority: Major
>
> Nightly builds of branch-2 have been failing on the "Packaging and
> Integration" stage since 2021-07-22, commit
> 8bc180c7737bbd1792851004625c552896bf57c6.
> The first failing build was
> https://ci-hadoop.apache.org/blue/organizations/jenkins/HBase%2FHBase%20Nightly/detail/branch-2/304/pipeline/12
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-26186) "Packaging and Integration" stage broken on branch-2 since 8bc180c7737bbd1792851004625c552896bf57c6
[
https://issues.apache.org/jira/browse/HBASE-26186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398301#comment-17398301
]
Sean Busbey commented on HBASE-26186:
-
that file had this info, so this might have been failing for longer:
{code}
-rw-r--r-- 1 jenkins jenkins 3555328 Jun 14 14:11 hadoop-3.1.1-bin.tar.gz
{code}
> "Packaging and Integration" stage broken on branch-2 since
> 8bc180c7737bbd1792851004625c552896bf57c6
> ---
>
> Key: HBASE-26186
> URL: https://issues.apache.org/jira/browse/HBASE-26186
> Project: HBase
> Issue Type: Task
> Components: build, integration tests
>Affects Versions: 2.5.0
>Reporter: Nick Dimiduk
>Priority: Major
>
> Nightly builds of branch-2 have been failing on the "Packaging and
> Integration" stage since 2021-07-22, commit
> 8bc180c7737bbd1792851004625c552896bf57c6.
> The first failing build was
> https://ci-hadoop.apache.org/blue/organizations/jenkins/HBase%2FHBase%20Nightly/detail/branch-2/304/pipeline/12
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [hbase] Apache-HBase commented on pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
Apache-HBase commented on pull request #3574: URL: https://github.com/apache/hbase/pull/3574#issuecomment-897991762 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 2m 21s | Docker mode activated. | ||| _ Prechecks _ | | +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. | | +1 :green_heart: | hbaseanti | 0m 0s | Patch does not have any anti-patterns. | | +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 10s | master passed | | +1 :green_heart: | compile | 3m 24s | master passed | | +1 :green_heart: | checkstyle | 1m 12s | master passed | | +1 :green_heart: | spotbugs | 2m 10s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 7s | the patch passed | | +1 :green_heart: | compile | 3m 23s | the patch passed | | +1 :green_heart: | javac | 3m 23s | the patch passed | | +1 :green_heart: | checkstyle | 1m 14s | hbase-server: The patch generated 0 new + 190 unchanged - 4 fixed = 190 total (was 194) | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +1 :green_heart: | hadoopcheck | 20m 11s | Patch does not cause any errors with Hadoop 3.1.2 3.2.1 3.3.0. | | +1 :green_heart: | spotbugs | 2m 21s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 12s | The patch does not generate ASF License warnings. | | | | 54m 50s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/4/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3574 | | Optional Tests | dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux ee4ad4a7f6cd 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 11222fc4df | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Max. process+thread count | 85 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/4/console | | versions | git=2.17.1 maven=3.6.3 spotbugs=4.2.2 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (HBASE-26193) Do not store meta region location on zookeeper
[ https://issues.apache.org/jira/browse/HBASE-26193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398316#comment-17398316 ] Zach York commented on HBASE-26193: --- Took a look, had some minor questions (apologies if they are relatively basic), but in general I agree, that seems like a feasible solution. > Do not store meta region location on zookeeper > -- > > Key: HBASE-26193 > URL: https://issues.apache.org/jira/browse/HBASE-26193 > Project: HBase > Issue Type: Improvement > Components: meta, Zookeeper >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > > As it breaks one of our design rules > https://hbase.apache.org/book.html#design.invariants.zk.data > We used to think hbase should be recovered automatically when all the data on > zk (except the replication data) are cleared, but obviously, if you clear the > meta region location, the cluster will be in trouble, and need to use > operation tools to recover the cluster. > So here, along with the ConnectionRegistry improvements, we should also > consider move the meta region location off zookeeper. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25849) Backport HBASE-22738 & HBASE-24760 (Fallback feature for RS groups when there are no RS in current group) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-25849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Zhou updated HBASE-25849: -- Summary: Backport HBASE-22738 & HBASE-24760 (Fallback feature for RS groups when there are no RS in current group) to branch-1 (was: Backport "HBASE-22738 Fallback to default group to choose RS when there are no RS in current group" and "HBASE-24760 Add a config hbase.rsgroup.fallback.enable for RSGroup fallback feature" to branch-1) > Backport HBASE-22738 & HBASE-24760 (Fallback feature for RS groups when there > are no RS in current group) to branch-1 > - > > Key: HBASE-25849 > URL: https://issues.apache.org/jira/browse/HBASE-25849 > Project: HBase > Issue Type: Improvement >Reporter: Caroline Zhou >Assignee: Caroline Zhou >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26193) Do not store meta region location on zookeeper
[ https://issues.apache.org/jira/browse/HBASE-26193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398341#comment-17398341 ] Michael Stack commented on HBASE-26193: --- [~zyork] Pardon. I was flagging you for the first part of the doc i.e. a fix so a populated hbase could start though zk is tabula rasa... (The second part of the doc seems to be an active working doc whose product would be a proposal over on the split meta Jira – will let Duo clarify). > Do not store meta region location on zookeeper > -- > > Key: HBASE-26193 > URL: https://issues.apache.org/jira/browse/HBASE-26193 > Project: HBase > Issue Type: Improvement > Components: meta, Zookeeper >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > > As it breaks one of our design rules > https://hbase.apache.org/book.html#design.invariants.zk.data > We used to think hbase should be recovered automatically when all the data on > zk (except the replication data) are cleared, but obviously, if you clear the > meta region location, the cluster will be in trouble, and need to use > operation tools to recover the cluster. > So here, along with the ConnectionRegistry improvements, we should also > consider move the meta region location off zookeeper. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26193) Do not store meta region location on zookeeper
[ https://issues.apache.org/jira/browse/HBASE-26193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398346#comment-17398346 ] Zach York commented on HBASE-26193: --- Yeah I saw that part, it sounds good, definitely a +1. Since the master local table perists the info in the root directory, it won't be lost even on a new cluster with existing data. In that case, we still will run into the problem described in HBASE-24286 for the meta table because we will: 1. Have a location for the meta existing 2. The meta table won't be open at that server (the server itself is likely dead) 3. We will wait for it to become open (it never will if there is no SCP) But obviously that's a different problem than this is trying to solve. > Do not store meta region location on zookeeper > -- > > Key: HBASE-26193 > URL: https://issues.apache.org/jira/browse/HBASE-26193 > Project: HBase > Issue Type: Improvement > Components: meta, Zookeeper >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > > As it breaks one of our design rules > https://hbase.apache.org/book.html#design.invariants.zk.data > We used to think hbase should be recovered automatically when all the data on > zk (except the replication data) are cleared, but obviously, if you clear the > meta region location, the cluster will be in trouble, and need to use > operation tools to recover the cluster. > So here, along with the ConnectionRegistry improvements, we should also > consider move the meta region location off zookeeper. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26195) Data is present in replicated cluster but not present in primary cluster.
[
https://issues.apache.org/jira/browse/HBASE-26195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398357#comment-17398357
]
Andrew Kyle Purtell commented on HBASE-26195:
-
Approach 3 is the correct approach. The other approaches are insufficient and
should not be considered. We are getting away from WAL as source of truth by
rolling back the memstore.
Append and sync are two separate operations. Without a successful sync we
cannot know if the append has been made durable and visible to replication WAL
tailers. Maybe, maybe not. We have seen source and sink sides of a replication
edge become inconsistent because of this scenario, triggered by a namenode
failover. However it seems possible, if rare, in any high load scenario.
We are only guaranteed to be fully consistent on both the source and sink sides
of a replication edge if we see both append and sync succeed, or if we abort
the regionserver if either the append or the sync fails. When we abort we cause
the system to fall back to the WAL as source of truth, for both source and sink
sides.
> Data is present in replicated cluster but not present in primary cluster.
> -
>
> Key: HBASE-26195
> URL: https://issues.apache.org/jira/browse/HBASE-26195
> Project: HBase
> Issue Type: Bug
> Components: Replication, wal
>Affects Versions: 3.0.0-alpha-1, 1.7.0, 2.5.0
>Reporter: Rushabh Shah
>Assignee: Rushabh Shah
>Priority: Major
>
> We encountered a case where we are seeing some rows (via Phoenix) in
> replicated cluster but they are not present in source/active cluster.
> Triaging further we found memstore rollback logs in few of the region servers.
> {noformat}
> 2021-07-28 14:17:59,353 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,353 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,354 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,355 DEBUG [3,queue=3,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,355 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> 2021-07-28 14:17:59,356 DEBUG [,queue=25,port=60020] regionserver.HRegion -
> rollbackMemstore rolled back 23
> {noformat}
> Looking more into logs, found that there were some hdfs layer issues sync'ing
> wal to hdfs.
> It was taking around 6 mins to sync wal. Logs below
> {noformat}
> 2021-07-28 14:19:30,511 WARN [sync.0] hdfs.DataStreamer - Slow
> waitForAckedSeqno took 391210ms (threshold=3ms). File being written:
> /hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
> block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
> pipeline datanodes:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
> 2021-07-28 14:19:30,589 WARN [sync.1] hdfs.DataStreamer - Slow
> waitForAckedSeqno took 391148ms (threshold=3ms). File being written:
> /hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
> block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
> pipeline datanodes:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
> 2021-07-28 14:19:30,589 WARN [sync.2] hdfs.DataStreamer - Slow
> waitForAckedSeqno took 391147ms (threshold=3ms). File being written:
> /hbase/WALs/,60020,1626191371499/%2C60020%2C1626191371499.1627480615620,
> block: BP-958889176--1567030695029:blk_1689647875_616028364, Write
> pipeline datanodes:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-505dabb0-0fd6-42d9-b25d-f25e249fe504,DISK],
>
> DatanodeInfoWithStorage[:50010,DS-6c585673-d4d0-4ec6-bafe-ad4cd861fb4b,DISK]].
> 2021-07-28 14:19:30,591 INFO [sync.0] wal.FSHLog - Slow sync cost: 391289
> ms, current pipeline:
> [DatanodeInfoWithStorage[:50010,DS-b5747702-8ab9-4a5e-916e-5fae6e305738,DISK],
>
> DatanodeI
[GitHub] [hbase] Apache-HBase commented on pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
Apache-HBase commented on pull request #3574: URL: https://github.com/apache/hbase/pull/3574#issuecomment-898071375 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 3s | Docker mode activated. | | -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 5m 7s | master passed | | +1 :green_heart: | compile | 1m 18s | master passed | | +1 :green_heart: | shadedjars | 9m 8s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 43s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 48s | the patch passed | | +1 :green_heart: | compile | 1m 19s | the patch passed | | +1 :green_heart: | javac | 1m 19s | the patch passed | | +1 :green_heart: | shadedjars | 8m 58s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 42s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 202m 2s | hbase-server in the patch passed. | | | | 237m 6s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/4/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3574 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 6e0a68a86607 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 11222fc4df | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/4/testReport/ | | Max. process+thread count | 2644 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/4/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3574: HBASE-26187 Write straight into the store directory when Splitting an…
Apache-HBase commented on pull request #3574: URL: https://github.com/apache/hbase/pull/3574#issuecomment-898083187 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 59s | Docker mode activated. | | -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 8s | master passed | | +1 :green_heart: | compile | 1m 3s | master passed | | +1 :green_heart: | shadedjars | 8m 59s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 37s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 8s | the patch passed | | +1 :green_heart: | compile | 1m 4s | the patch passed | | +1 :green_heart: | javac | 1m 4s | the patch passed | | +1 :green_heart: | shadedjars | 9m 5s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 36s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 220m 11s | hbase-server in the patch passed. | | | | 253m 27s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/4/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3574 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 27ccc1febfd9 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 11222fc4df | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/4/testReport/ | | Max. process+thread count | 2555 (vs. ulimit of 3) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3574/4/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3581: HBASE-25849 Backport HBASE-22738 & HBASE-24760 (Fallback feature for RS groups when there are no RS in current group) to branch-1
Apache-HBase commented on pull request #3581: URL: https://github.com/apache/hbase/pull/3581#issuecomment-898106626 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 6m 42s | Docker mode activated. | ||| _ Prechecks _ | | +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. | | +1 :green_heart: | hbaseanti | 0m 0s | Patch does not have any anti-patterns. | | +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. | | +1 :green_heart: | test4tests | 0m 0s | The patch appears to include 3 new or modified test files. | ||| _ branch-1 Compile Tests _ | | +0 :ok: | mvndep | 2m 31s | Maven dependency ordering for branch | | +1 :green_heart: | mvninstall | 8m 6s | branch-1 passed | | +1 :green_heart: | compile | 0m 58s | branch-1 passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | compile | 1m 9s | branch-1 passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | +1 :green_heart: | checkstyle | 1m 57s | branch-1 passed | | +1 :green_heart: | shadedjars | 3m 3s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 57s | branch-1 passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | javadoc | 0m 58s | branch-1 passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | +0 :ok: | spotbugs | 2m 42s | Used deprecated FindBugs config; considering switching to SpotBugs. | | +1 :green_heart: | findbugs | 3m 47s | branch-1 passed | ||| _ Patch Compile Tests _ | | +0 :ok: | mvndep | 0m 19s | Maven dependency ordering for patch | | +1 :green_heart: | mvninstall | 1m 51s | the patch passed | | +1 :green_heart: | compile | 1m 0s | the patch passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | javac | 1m 0s | the patch passed | | +1 :green_heart: | compile | 1m 9s | the patch passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | +1 :green_heart: | javac | 1m 9s | the patch passed | | -1 :x: | checkstyle | 1m 32s | hbase-server: The patch generated 2 new + 24 unchanged - 0 fixed = 26 total (was 24) | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +1 :green_heart: | shadedjars | 2m 54s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | hadoopcheck | 4m 38s | Patch does not cause any errors with Hadoop 2.8.5 2.9.2. | | +1 :green_heart: | javadoc | 0m 46s | the patch passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | javadoc | 0m 58s | the patch passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | -1 :x: | findbugs | 1m 0s | hbase-rsgroup generated 2 new + 0 unchanged - 0 fixed = 2 total (was 0) | ||| _ Other Tests _ | | +1 :green_heart: | unit | 132m 45s | hbase-server in the patch passed. | | +1 :green_heart: | unit | 14m 29s | hbase-rsgroup in the patch passed. | | +1 :green_heart: | asflicense | 0m 59s | The patch does not generate ASF License warnings. | | | | 201m 38s | | | Reason | Tests | |---:|:--| | FindBugs | module:hbase-rsgroup | | | org.apache.hadoop.hbase.rsgroup.RSGroupBasedLoadBalancer.retainAssignment(Map, List) makes inefficient use of keySet iterator instead of entrySet iterator At RSGroupBasedLoadBalancer.java:of keySet iterator instead of entrySet iterator At RSGroupBasedLoadBalancer.java:[line 227] | | | org.apache.hadoop.hbase.rsgroup.RSGroupBasedLoadBalancer.roundRobinAssignment(List, List) makes inefficient use of keySet iterator instead of entrySet iterator At RSGroupBasedLoadBalancer.java:of keySet iterator instead of entrySet iterator At RSGroupBasedLoadBalancer.java:[line 201] | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3581/1/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3581 | | Optional Tests | dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux 721f8da151e9 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /home/jenkins/jenkins-home/workspace/Base-PreCommit-GitHub-PR_PR-3581/out/precommit/personality/provided.sh | | git revision | branch-1 / 75844c8 | | Default Java | Azul Systems, Inc.-1.7.0_272-b10 | | Multi-JDK versions | /usr/lib/jvm/zulu-8-amd64:Azul Systems, Inc.-1.8.0_262-b19 /usr/lib/jvm/zulu-7-amd64:
[jira] [Created] (HBASE-26196) Support configuration override for remote cluster of HFileOutputFormat locality sensitive
Shinya Yoshida created HBASE-26196: -- Summary: Support configuration override for remote cluster of HFileOutputFormat locality sensitive Key: HBASE-26196 URL: https://issues.apache.org/jira/browse/HBASE-26196 Project: HBase Issue Type: Bug Components: mapreduce Affects Versions: 2.4.5, 1.8.0, 3.0.0-alpha-2 Reporter: Shinya Yoshida Assignee: Shinya Yoshida We introduced support to generate hfile with good locality for a remote cluster even in HBASE-25608. I realized we need to override other configurations for the remote cluster in addition to the zookeeper cluster key. For example, read from a non-secure cluster and write hfiles for a secure cluster. In this case, we use TableInputFormat for non-secure cluster with hbase.security.authentication=simple in job configuration. So HFileOutputFormat failed to connect to remote secure cluster because requires hbase.security.authentication=kerberos in job conf. Another example is to read from a secure cluster (A) and write hfiles for another secure cluster (B) and we use different principal for each cluster. For instance, we use cluster-a/_h...@example.com for A and cluster-b/_h...@example.com for B. Then we need to override MASTER_KRB_PRINCIPAL and REGIONSERVER_KRB_PRINCIPAL using cluster-b/_h...@example.com to connect cluster B. Thus let's introduce configuration override for remote-cluster-aware HFileOutputFormat locality-sensitive feature. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26026) HBase Write may be stuck forever when using CompactingMemStore
[
https://issues.apache.org/jira/browse/HBASE-26026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398399#comment-17398399
]
Hudson commented on HBASE-26026:
Results for branch branch-2.4
[build #179 on
builds.a.o|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/General_20Nightly_20Build_20Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/JDK8_20Nightly_20Build_20Report_20_28Hadoop2_29/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 jdk11 hadoop3 checks{color}
-- For more information [see jdk11
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/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}
> HBase Write may be stuck forever when using CompactingMemStore
> --
>
> Key: HBASE-26026
> URL: https://issues.apache.org/jira/browse/HBASE-26026
> Project: HBase
> Issue Type: Bug
> Components: in-memory-compaction
>Affects Versions: 3.0.0-alpha-1, 2.3.0, 2.4.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Critical
> Fix For: 2.5.0, 3.0.0-alpha-2, 2.4.6, 2.3.7
>
>
> Sometimes I observed that HBase Write might be stuck in my hbase cluster
> which enabling {{CompactingMemStore}}. I have simulated the problem by unit
> test in my PR.
> The problem is caused by {{CompactingMemStore.checkAndAddToActiveSize}} :
> {code:java}
> 425 private boolean checkAndAddToActiveSize(MutableSegment currActive, Cell
> cellToAdd,
> 426 MemStoreSizing memstoreSizing) {
> 427if (shouldFlushInMemory(currActive, cellToAdd, memstoreSizing)) {
> 428 if (currActive.setInMemoryFlushed()) {
> 429flushInMemory(currActive);
> 430if (setInMemoryCompactionFlag()) {
> 431 // The thread is dispatched to do in-memory compaction in the
> background
> ..
> }
> {code}
> In line 427, {{shouldFlushInMemory}} checking if {{currActive.getDataSize}}
> adding the size of {{cellToAdd}} exceeds
> {{CompactingMemStore.inmemoryFlushSize}},if true, then {{currActive}}
> should be flushed, {{currActive.setInMemoryFlushed()}} is invoked in line
> 428 ：
> {code:java}
> public boolean setInMemoryFlushed() {
> return flushed.compareAndSet(false, true);
> }
> {code}
> After sucessfully set {{currActive.flushed}} to true, in above line 429
> {{flushInMemory(currActive)}} invokes
> {{CompactingMemStore.pushActiveToPipeline}} :
> {code:java}
> protected void pushActiveToPipeline(MutableSegment currActive) {
> if (!currActive.isEmpty()) {
> pipeline.pushHead(currActive);
> resetActive();
> }
> }
> {code}
> In above {{CompactingMemStore.pushActiveToPipeline}} method , if the
> {{currActive.cellSet}} is empty, then nothing is done. Due to concurrent
> writes and because we first add cell size to {{currActive.getDataSize}} and
> then actually add cell to {{currActive.cellSet}}, it is possible that
> {{currActive.getDataSize}} could not accommodate {{cellToAdd}} but
> {{currActive.cellSet}} is still empty if pending writes which not yet add
> cells to {{currActive.cellSet}}.
> So if the {{currActive.cellSet}} is empty now, then no {{ActiveSegment}} is
> created, and new writes still continue target to {{currActive}}, but
> {{currActive.flushed}} is true, {{currActive}} could not enter
> {{flushInMemory(currActive)}} again，and new {{ActiveSegment}} could not be
> created forever ! In the end all writes would be stuck.
> In my opinion , once {{currActive.flushed}} is set true, it could not
> continue use as {{ActiveSegment}} , and because of concurrent pending writes,
> only after {{currActive.updatesLock.writeLock()}} is acquired(i.e.
> {{currActive.waitForUpdates}} is called) in
> {{CompactingMemStore.inMemoryCompaction}} ,we can safely say {{currActive}}
> is empty or not.
> My fix is remove the {{if (!currActive.isEmpty())}} check here and left the
> check to background {{InMemoryCompactionRunnable}} after
> {{currActive.waitForUpdates}} is called. An alternative fix is we use
> synchronization mechanism in
[jira] [Commented] (HBASE-26185) Fix TestMaster#testMoveRegionWhenNotInitialized with hbase.min.version.move.system.tables
[
https://issues.apache.org/jira/browse/HBASE-26185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398396#comment-17398396
]
Hudson commented on HBASE-26185:
Results for branch branch-2.4
[build #179 on
builds.a.o|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/General_20Nightly_20Build_20Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/JDK8_20Nightly_20Build_20Report_20_28Hadoop2_29/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 jdk11 hadoop3 checks{color}
-- For more information [see jdk11
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/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}
> Fix TestMaster#testMoveRegionWhenNotInitialized with
> hbase.min.version.move.system.tables
> -
>
> Key: HBASE-26185
> URL: https://issues.apache.org/jira/browse/HBASE-26185
> Project: HBase
> Issue Type: Test
>Reporter: Viraj Jasani
>Assignee: Rushabh Shah
>Priority: Minor
> Fix For: 2.5.0, 3.0.0-alpha-2, 1.7.2, 2.4.6, 2.3.7
>
>
> In order to protect meta region movement unexpectedly during upgrade with
> rsGroup enabled, it is good practice to keep
> hbase.min.version.move.system.tables in hbase-default for specific branch so
> that the use-case for the specific version of HBase is well under control.
> However, TestMaster#testMoveRegionWhenNotInitialized would fail because it
> would not find server to move meta to. We should fix this.
>
> {code:java}
> INFO [Time-limited test] master.HMaster(2029): Passed destination servername
> is null/empty so choosing a server at random
> java.lang.UnsupportedOperationExceptionjava.lang.UnsupportedOperationException
> at java.util.AbstractList.add(AbstractList.java:148) at
> java.util.AbstractList.add(AbstractList.java:108) at
> org.apache.hadoop.hbase.master.HMaster.move(HMaster.java:2031) at
> org.apache.hadoop.hbase.master.TestMaster.testMoveRegionWhenNotInitialized(TestMaster.java:181)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-26155) JVM crash when scan
[
https://issues.apache.org/jira/browse/HBASE-26155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398397#comment-17398397
]
Hudson commented on HBASE-26155:
Results for branch branch-2.4
[build #179 on
builds.a.o|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/General_20Nightly_20Build_20Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/JDK8_20Nightly_20Build_20Report_20_28Hadoop2_29/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 jdk11 hadoop3 checks{color}
-- For more information [see jdk11
report|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/179/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}
> JVM crash when scan
> ---
>
> Key: HBASE-26155
> URL: https://issues.apache.org/jira/browse/HBASE-26155
> Project: HBase
> Issue Type: Bug
> Components: Scanners
>Affects Versions: 3.0.0-alpha-1
>Reporter: Xiaolin Ha
>Assignee: Xiaolin Ha
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.6, 2.3.7
>
> Attachments: scan-error.png
>
>
> There are scanner close caused regionserver JVM coredump problems on our
> production clusters.
> {code:java}
> Stack: [0x7fca4b0cc000,0x7fca4b1cd000], sp=0x7fca4b1cb0d8, free
> space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V [libjvm.so+0x7fd314]
> J 2810 sun.misc.Unsafe.copyMemory(Ljava/lang/Object;JLjava/lang/Object;JJ)V
> (0 bytes) @ 0x7fdae55a9e61 [0x7fdae55a9d80+0xe1]
> j
> org.apache.hadoop.hbase.util.UnsafeAccess.unsafeCopy(Ljava/lang/Object;JLjava/lang/Object;JJ)V+36
> j
> org.apache.hadoop.hbase.util.UnsafeAccess.copy(Ljava/nio/ByteBuffer;I[BII)V+69
> j
> org.apache.hadoop.hbase.util.ByteBufferUtils.copyFromBufferToArray([BLjava/nio/ByteBuffer;III)V+39
> j
> org.apache.hadoop.hbase.CellUtil.copyQualifierTo(Lorg/apache/hadoop/hbase/Cell;[BI)I+31
> j
> org.apache.hadoop.hbase.KeyValueUtil.appendKeyTo(Lorg/apache/hadoop/hbase/Cell;[BI)I+43
> J 14724 C2 org.apache.hadoop.hbase.regionserver.StoreScanner.shipped()V (51
> bytes) @ 0x7fdae6a298d0 [0x7fdae6a29780+0x150]
> J 21387 C2
> org.apache.hadoop.hbase.regionserver.RSRpcServices$RegionScannerShippedCallBack.run()V
> (53 bytes) @ 0x7fdae622bab8 [0x7fdae622acc0+0xdf8]
> J 26353 C2
> org.apache.hadoop.hbase.ipc.ServerCall.setResponse(Lorg/apache/hbase/thirdparty/com/google/protobuf/Message;Lorg/apache/hadoop/hbase/CellScanner;Ljava/lang/Throwable;Ljava/lang/String;)V
> (384 bytes) @ 0x7fdae7f139d8 [0x7fdae7f12980+0x1058]
> J 26226 C2 org.apache.hadoop.hbase.ipc.CallRunner.run()V (1554 bytes) @
> 0x7fdae959f68c [0x7fdae959e400+0x128c]
> J 19598% C2
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(Ljava/util/concurrent/BlockingQueue;Ljava/util/concurrent/atomic/AtomicInteger;)V
> (338 bytes) @ 0x7fdae81c54d4 [0x7fdae81c53e0+0xf4]
> {code}
> There are also scan rpc errors when coredump happens at the handler,
> !scan-error.png|width=585,height=235!
> I found some clue in the logs, that some blocks may be replaced when its
> nextBlockOnDiskSize less than the newly one in the method
>
> {code:java}
> public static boolean shouldReplaceExistingCacheBlock(BlockCache blockCache,
> BlockCacheKey cacheKey, Cacheable newBlock) {
> if (cacheKey.toString().indexOf(".") != -1) { // reference file
> LOG.warn("replace existing cached block, cache key is : " + cacheKey);
> return true;
> }
> Cacheable existingBlock = blockCache.getBlock(cacheKey, false, false,
> false);
> if (existingBlock == null) {
> return true;
> }
> try {
> int comparison = BlockCacheUtil.validateBlockAddition(existingBlock,
> newBlock, cacheKey);
> if (comparison < 0) {
> LOG.warn("Cached block contents differ by nextBlockOnDiskSize, the new
> block has "
> + "nextBlockOnDiskSize set. Caching new block.");
> return true;
> ..{code}
>
> And the block will be replaced if it is not in the RAMCache but in the
> BucketCache.
> When using
>
> {code:java}
> private
[jira] [Updated] (HBASE-26196) Support configuration override for remote cluster of HFileOutputFormat locality sensitive
[ https://issues.apache.org/jira/browse/HBASE-26196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shinya Yoshida updated HBASE-26196: --- Description: We introduced support to generate hfile with good locality for a remote cluster even in HBASE-25608. I realized we need to override other configurations for the remote cluster in addition to the zookeeper cluster key. For example, read from a non-secure cluster and write hfiles for a secure cluster. In this case, we use TableInputFormat for non-secure cluster with hbase.security.authentication=simple in job configuration. So HFileOutputFormat failed to connect to remote secure cluster because requires hbase.security.authentication=kerberos in job conf. Thus let's introduce configuration override for remote-cluster-aware HFileOutputFormat locality-sensitive feature. -Another example is to read from a secure cluster (A) and write hfiles for another secure cluster (B) and we use different principal for each cluster.- -For instance, we use cluster-a/_h...@example.com for A and cluster-b/_h...@example.com for B.- -Then we need to override MASTER_KRB_PRINCIPAL and REGIONSERVER_KRB_PRINCIPAL using cluster-b/_h...@example.com to connect cluster B.- ^ This is not truth, we use token based digest auth in MR job, so this should be fine was: We introduced support to generate hfile with good locality for a remote cluster even in HBASE-25608. I realized we need to override other configurations for the remote cluster in addition to the zookeeper cluster key. For example, read from a non-secure cluster and write hfiles for a secure cluster. In this case, we use TableInputFormat for non-secure cluster with hbase.security.authentication=simple in job configuration. So HFileOutputFormat failed to connect to remote secure cluster because requires hbase.security.authentication=kerberos in job conf. Another example is to read from a secure cluster (A) and write hfiles for another secure cluster (B) and we use different principal for each cluster. For instance, we use cluster-a/_h...@example.com for A and cluster-b/_h...@example.com for B. Then we need to override MASTER_KRB_PRINCIPAL and REGIONSERVER_KRB_PRINCIPAL using cluster-b/_h...@example.com to connect cluster B. Thus let's introduce configuration override for remote-cluster-aware HFileOutputFormat locality-sensitive feature. > Support configuration override for remote cluster of HFileOutputFormat > locality sensitive > - > > Key: HBASE-26196 > URL: https://issues.apache.org/jira/browse/HBASE-26196 > Project: HBase > Issue Type: Bug > Components: mapreduce >Affects Versions: 1.8.0, 3.0.0-alpha-2, 2.4.5 >Reporter: Shinya Yoshida >Assignee: Shinya Yoshida >Priority: Major > > We introduced support to generate hfile with good locality for a remote > cluster even in HBASE-25608. > I realized we need to override other configurations for the remote cluster in > addition to the zookeeper cluster key. > For example, read from a non-secure cluster and write hfiles for a secure > cluster. > In this case, we use TableInputFormat for non-secure cluster with > hbase.security.authentication=simple in job configuration. > So HFileOutputFormat failed to connect to remote secure cluster because > requires hbase.security.authentication=kerberos in job conf. > > Thus let's introduce configuration override for remote-cluster-aware > HFileOutputFormat locality-sensitive feature. > > -Another example is to read from a secure cluster (A) and write hfiles for > another secure cluster (B) and we use different principal for each cluster.- > -For instance, we use cluster-a/_h...@example.com for A and > cluster-b/_h...@example.com for B.- > -Then we need to override MASTER_KRB_PRINCIPAL and > REGIONSERVER_KRB_PRINCIPAL using cluster-b/_h...@example.com to connect > cluster B.- > ^ This is not truth, we use token based digest auth in MR job, so this should > be fine -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26026) HBase Write may be stuck forever when using CompactingMemStore
[
https://issues.apache.org/jira/browse/HBASE-26026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398403#comment-17398403
]
chenglei commented on HBASE-26026:
--
[~zhangduo], [~apurtell]， thank you very much for code review.
> HBase Write may be stuck forever when using CompactingMemStore
> --
>
> Key: HBASE-26026
> URL: https://issues.apache.org/jira/browse/HBASE-26026
> Project: HBase
> Issue Type: Bug
> Components: in-memory-compaction
>Affects Versions: 3.0.0-alpha-1, 2.3.0, 2.4.0
>Reporter: chenglei
>Assignee: chenglei
>Priority: Critical
> Fix For: 2.5.0, 3.0.0-alpha-2, 2.4.6, 2.3.7
>
>
> Sometimes I observed that HBase Write might be stuck in my hbase cluster
> which enabling {{CompactingMemStore}}. I have simulated the problem by unit
> test in my PR.
> The problem is caused by {{CompactingMemStore.checkAndAddToActiveSize}} :
> {code:java}
> 425 private boolean checkAndAddToActiveSize(MutableSegment currActive, Cell
> cellToAdd,
> 426 MemStoreSizing memstoreSizing) {
> 427if (shouldFlushInMemory(currActive, cellToAdd, memstoreSizing)) {
> 428 if (currActive.setInMemoryFlushed()) {
> 429flushInMemory(currActive);
> 430if (setInMemoryCompactionFlag()) {
> 431 // The thread is dispatched to do in-memory compaction in the
> background
> ..
> }
> {code}
> In line 427, {{shouldFlushInMemory}} checking if {{currActive.getDataSize}}
> adding the size of {{cellToAdd}} exceeds
> {{CompactingMemStore.inmemoryFlushSize}},if true, then {{currActive}}
> should be flushed, {{currActive.setInMemoryFlushed()}} is invoked in line
> 428 ：
> {code:java}
> public boolean setInMemoryFlushed() {
> return flushed.compareAndSet(false, true);
> }
> {code}
> After sucessfully set {{currActive.flushed}} to true, in above line 429
> {{flushInMemory(currActive)}} invokes
> {{CompactingMemStore.pushActiveToPipeline}} :
> {code:java}
> protected void pushActiveToPipeline(MutableSegment currActive) {
> if (!currActive.isEmpty()) {
> pipeline.pushHead(currActive);
> resetActive();
> }
> }
> {code}
> In above {{CompactingMemStore.pushActiveToPipeline}} method , if the
> {{currActive.cellSet}} is empty, then nothing is done. Due to concurrent
> writes and because we first add cell size to {{currActive.getDataSize}} and
> then actually add cell to {{currActive.cellSet}}, it is possible that
> {{currActive.getDataSize}} could not accommodate {{cellToAdd}} but
> {{currActive.cellSet}} is still empty if pending writes which not yet add
> cells to {{currActive.cellSet}}.
> So if the {{currActive.cellSet}} is empty now, then no {{ActiveSegment}} is
> created, and new writes still continue target to {{currActive}}, but
> {{currActive.flushed}} is true, {{currActive}} could not enter
> {{flushInMemory(currActive)}} again，and new {{ActiveSegment}} could not be
> created forever ! In the end all writes would be stuck.
> In my opinion , once {{currActive.flushed}} is set true, it could not
> continue use as {{ActiveSegment}} , and because of concurrent pending writes,
> only after {{currActive.updatesLock.writeLock()}} is acquired(i.e.
> {{currActive.waitForUpdates}} is called) in
> {{CompactingMemStore.inMemoryCompaction}} ,we can safely say {{currActive}}
> is empty or not.
> My fix is remove the {{if (!currActive.isEmpty())}} check here and left the
> check to background {{InMemoryCompactionRunnable}} after
> {{currActive.waitForUpdates}} is called. An alternative fix is we use
> synchronization mechanism in {{checkAndAddToActiveSize}} method to prevent
> all writes , wait for all pending write completed(i.e.
> currActive.waitForUpdates is called) and if {{currActive}} is still empty
> ,then we set {{currActive.flushed}} back to false,but I am not inclined to
> use so heavy synchronization in write path, and I think we would better
> maintain lockless implementation for {{CompactingMemStore.add}} method just
> as now and {{currActive.waitForUpdates}} would better be left in background
> {{InMemoryCompactionRunnable}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [hbase] bitterfox opened a new pull request #3582: HBASE-26196 Support configuration override for remote cluster of HFileOutputFormat locality sensitive
bitterfox opened a new pull request #3582:
URL: https://github.com/apache/hbase/pull/3582
https://issues.apache.org/jira/browse/HBASE-26196
Usecase:
```
TableName tableName = TableName.valueOf("table");
Configuration conf = job.getConfiguration();
// assume cluster B is secure
Configuration clusterB = HBaseConfiguration.createClusterConf(
conf,
"hbase-b-1.example.com,hbase-b-2.example.com,hbase-b-3.example.com:2181:/hbase-b");
clusterB.set(User.HBASE_SECURITY_CONF_KEY, "kerberos");
// configure others too like MASTER_KRB_PRINCIPAL,
REGIONSERVER_KRB_PRINCIPAL and so on
// hack. TableMapReduceUtil.initCredentialsForCluster create
UserProvider using job's configuration
// Thus if User.HBASE_SECURITY_CONF_KEY is simple, token isn't
obtained
conf.set(User.HBASE_SECURITY_CONF_KEY, "kerberos");
TableMapReduceUtil.initCredentialsForCluster(job, clusterB);
// assume cluster A isn't secure
conf.set(HConstants.ZOOKEEPER_QUORUM,
"hbase-a-1.example.com,hbase-a-2.example.com,hbase-a-3.example.com");
conf.setInt(HConstants.ZOOKEEPER_CLIENT_PORT, 2181);
conf.set(HConstants.ZOOKEEPER_ZNODE_PARENT, "/hbase-a");
conf.set(User.HBASE_SECURITY_CONF_KEY, "simple");
TableMapReduceUtil.initTableMapperJob(tableName, scanner,
Mapper.class, ImmutableBytesWritable.class, Put.class, job);
try (Connection con = ConnectionFactory.createConnection(clusterB);
Table table = con.getTable(tableName);
RegionLocator regionLocator = con.getRegionLocator(tableName)) {
HFileOutputFormat2.configureIncrementalLoad(job, table,
regionLocator);
conf.set(HFileOutputFormat2.REMOTE_CLUSTER_CONF_PREFIX +
User.HBASE_SECURITY_CONF_KEY, "kerberos");
}
return job.waitForCompletion(true) ? 0 : 1;
```
--
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: issues-unsubscr...@hbase.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (HBASE-26196) Support configuration override for remote cluster of HFileOutputFormat locality sensitive
[ https://issues.apache.org/jira/browse/HBASE-26196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shinya Yoshida updated HBASE-26196: --- Description: We introduced support to generate hfile with good locality for a remote cluster even in HBASE-25608. I realized we need to override other configurations for the remote cluster in addition to the zookeeper cluster key. For example, read from a non-secure cluster and write hfiles for a secure cluster. In this case, we use TableInputFormat for non-secure cluster with hbase.security.authentication=simple in job configuration. So HFileOutputFormat failed to connect to remote secure cluster because requires hbase.security.authentication=kerberos in job conf. Thus let's introduce configuration override for remote-cluster-aware HFileOutputFormat locality-sensitive feature. -Another example is to read from a secure cluster (A) and write hfiles for another secure cluster (B) and we use different principal for each cluster.- -For instance, we use cluster-a/_h...@example.com for A and cluster-b/_h...@example.com for B.- -Then we need to override MASTER_KRB_PRINCIPAL and REGIONSERVER_KRB_PRINCIPAL using cluster-b/_h...@example.com to connect cluster B.- ^ This is not truth, we use token based digest auth in mapper/reducer, so principal difference for kerberos should be fine was: We introduced support to generate hfile with good locality for a remote cluster even in HBASE-25608. I realized we need to override other configurations for the remote cluster in addition to the zookeeper cluster key. For example, read from a non-secure cluster and write hfiles for a secure cluster. In this case, we use TableInputFormat for non-secure cluster with hbase.security.authentication=simple in job configuration. So HFileOutputFormat failed to connect to remote secure cluster because requires hbase.security.authentication=kerberos in job conf. Thus let's introduce configuration override for remote-cluster-aware HFileOutputFormat locality-sensitive feature. -Another example is to read from a secure cluster (A) and write hfiles for another secure cluster (B) and we use different principal for each cluster.- -For instance, we use cluster-a/_h...@example.com for A and cluster-b/_h...@example.com for B.- -Then we need to override MASTER_KRB_PRINCIPAL and REGIONSERVER_KRB_PRINCIPAL using cluster-b/_h...@example.com to connect cluster B.- ^ This is not truth, we use token based digest auth in MR job, so this should be fine > Support configuration override for remote cluster of HFileOutputFormat > locality sensitive > - > > Key: HBASE-26196 > URL: https://issues.apache.org/jira/browse/HBASE-26196 > Project: HBase > Issue Type: Bug > Components: mapreduce >Affects Versions: 1.8.0, 3.0.0-alpha-2, 2.4.5 >Reporter: Shinya Yoshida >Assignee: Shinya Yoshida >Priority: Major > > We introduced support to generate hfile with good locality for a remote > cluster even in HBASE-25608. > I realized we need to override other configurations for the remote cluster in > addition to the zookeeper cluster key. > For example, read from a non-secure cluster and write hfiles for a secure > cluster. > In this case, we use TableInputFormat for non-secure cluster with > hbase.security.authentication=simple in job configuration. > So HFileOutputFormat failed to connect to remote secure cluster because > requires hbase.security.authentication=kerberos in job conf. > > Thus let's introduce configuration override for remote-cluster-aware > HFileOutputFormat locality-sensitive feature. > > -Another example is to read from a secure cluster (A) and write hfiles for > another secure cluster (B) and we use different principal for each cluster.- > -For instance, we use cluster-a/_h...@example.com for A and > cluster-b/_h...@example.com for B.- > -Then we need to override MASTER_KRB_PRINCIPAL and > REGIONSERVER_KRB_PRINCIPAL using cluster-b/_h...@example.com to connect > cluster B.- > ^ This is not truth, we use token based digest auth in mapper/reducer, so > principal difference for kerberos should be fine -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [hbase] Apache-HBase commented on pull request #3582: HBASE-26196 Support configuration override for remote cluster of HFileOutputFormat locality sensitive
Apache-HBase commented on pull request #3582: URL: https://github.com/apache/hbase/pull/3582#issuecomment-898170415 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 26s | Docker mode activated. | | -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 2s | master passed | | +1 :green_heart: | compile | 0m 27s | master passed | | +1 :green_heart: | shadedjars | 8m 9s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 21s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 3m 43s | the patch passed | | +1 :green_heart: | compile | 0m 26s | the patch passed | | +1 :green_heart: | javac | 0m 26s | the patch passed | | +1 :green_heart: | shadedjars | 8m 12s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 19s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 11m 7s | hbase-mapreduce in the patch passed. | | | | 38m 22s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3582/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3582 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 51fec86558d9 4.15.0-151-generic #157-Ubuntu SMP Fri Jul 9 23:07:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 11222fc4df | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3582/1/testReport/ | | Max. process+thread count | 4025 (vs. ulimit of 3) | | modules | C: hbase-mapreduce U: hbase-mapreduce | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3582/1/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (HBASE-26193) Do not store meta region location on zookeeper
[
https://issues.apache.org/jira/browse/HBASE-26193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398424#comment-17398424
]
Michael Stack commented on HBASE-26193:
---
{quote}But obviously that's a different problem than this is trying to solve.
{quote}
Thanks [~zyork] My bad. Thought it would help (Would be kinda silly though if
the Master renewed a meta location that was for a server that was not a member
of the current cluster ... can look more if this goes in).
> Do not store meta region location on zookeeper
> --
>
> Key: HBASE-26193
> URL: https://issues.apache.org/jira/browse/HBASE-26193
> Project: HBase
> Issue Type: Improvement
> Components: meta, Zookeeper
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
>
> As it breaks one of our design rules
> https://hbase.apache.org/book.html#design.invariants.zk.data
> We used to think hbase should be recovered automatically when all the data on
> zk (except the replication data) are cleared, but obviously, if you clear the
> meta region location, the cluster will be in trouble, and need to use
> operation tools to recover the cluster.
> So here, along with the ConnectionRegistry improvements, we should also
> consider move the meta region location off zookeeper.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [hbase] Apache-HBase commented on pull request #3582: HBASE-26196 Support configuration override for remote cluster of HFileOutputFormat locality sensitive
Apache-HBase commented on pull request #3582: URL: https://github.com/apache/hbase/pull/3582#issuecomment-898171397 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 2s | Docker mode activated. | ||| _ Prechecks _ | | +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. | | +1 :green_heart: | hbaseanti | 0m 0s | Patch does not have any anti-patterns. | | +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 24s | master passed | | +1 :green_heart: | compile | 0m 47s | master passed | | +1 :green_heart: | checkstyle | 0m 20s | master passed | | +1 :green_heart: | spotbugs | 0m 47s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 4s | the patch passed | | +1 :green_heart: | compile | 0m 44s | the patch passed | | -0 :warning: | javac | 0m 44s | hbase-mapreduce generated 1 new + 197 unchanged - 1 fixed = 198 total (was 198) | | -0 :warning: | checkstyle | 0m 18s | hbase-mapreduce: The patch generated 1 new + 40 unchanged - 0 fixed = 41 total (was 40) | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +1 :green_heart: | hadoopcheck | 20m 28s | Patch does not cause any errors with Hadoop 3.1.2 3.2.1 3.3.0. | | +1 :green_heart: | spotbugs | 0m 55s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 13s | The patch does not generate ASF License warnings. | | | | 42m 17s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3582/1/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3582 | | Optional Tests | dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux c2a6b551c3f3 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 11222fc4df | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | javac | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3582/1/artifact/yetus-general-check/output/diff-compile-javac-hbase-mapreduce.txt | | checkstyle | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3582/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-mapreduce.txt | | Max. process+thread count | 86 (vs. ulimit of 3) | | modules | C: hbase-mapreduce U: hbase-mapreduce | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3582/1/console | | versions | git=2.17.1 maven=3.6.3 spotbugs=4.2.2 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #3582: HBASE-26196 Support configuration override for remote cluster of HFileOutputFormat locality sensitive
Apache-HBase commented on pull request #3582: URL: https://github.com/apache/hbase/pull/3582#issuecomment-898172275 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 5s | Docker mode activated. | | -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 5m 4s | master passed | | +1 :green_heart: | compile | 0m 30s | master passed | | +1 :green_heart: | shadedjars | 9m 5s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 22s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 47s | the patch passed | | +1 :green_heart: | compile | 0m 28s | the patch passed | | +1 :green_heart: | javac | 0m 28s | the patch passed | | +1 :green_heart: | shadedjars | 9m 11s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 20s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 13m 56s | hbase-mapreduce in the patch passed. | | | | 45m 51s | | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3582/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3582 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux f0878c386829 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 11222fc4df | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3582/1/testReport/ | | Max. process+thread count | 2901 (vs. ulimit of 3) | | modules | C: hbase-mapreduce U: hbase-mapreduce | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3582/1/console | | versions | git=2.17.1 maven=3.6.3 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (HBASE-26196) Support configuration override for remote cluster of HFileOutputFormat locality sensitive
[ https://issues.apache.org/jira/browse/HBASE-26196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shinya Yoshida updated HBASE-26196: --- Status: Patch Available (was: Open) > Support configuration override for remote cluster of HFileOutputFormat > locality sensitive > - > > Key: HBASE-26196 > URL: https://issues.apache.org/jira/browse/HBASE-26196 > Project: HBase > Issue Type: Bug > Components: mapreduce >Affects Versions: 2.4.5, 1.8.0, 3.0.0-alpha-2 >Reporter: Shinya Yoshida >Assignee: Shinya Yoshida >Priority: Major > > We introduced support to generate hfile with good locality for a remote > cluster even in HBASE-25608. > I realized we need to override other configurations for the remote cluster in > addition to the zookeeper cluster key. > For example, read from a non-secure cluster and write hfiles for a secure > cluster. > In this case, we use TableInputFormat for non-secure cluster with > hbase.security.authentication=simple in job configuration. > So HFileOutputFormat failed to connect to remote secure cluster because > requires hbase.security.authentication=kerberos in job conf. > > Thus let's introduce configuration override for remote-cluster-aware > HFileOutputFormat locality-sensitive feature. > > -Another example is to read from a secure cluster (A) and write hfiles for > another secure cluster (B) and we use different principal for each cluster.- > -For instance, we use cluster-a/_h...@example.com for A and > cluster-b/_h...@example.com for B.- > -Then we need to override MASTER_KRB_PRINCIPAL and > REGIONSERVER_KRB_PRINCIPAL using cluster-b/_h...@example.com to connect > cluster B.- > ^ This is not truth, we use token based digest auth in mapper/reducer, so > principal difference for kerberos should be fine -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26193) Do not store meta region location on zookeeper
[ https://issues.apache.org/jira/browse/HBASE-26193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398443#comment-17398443 ] Duo Zhang commented on HBASE-26193: --- This could solve part of the problem but not all. IIRC, there is still another problem is that, we need the WAL directory of a region server to be present even if flushed all the data and there is no data under the WAL directory. When starting master, we will scan the WAL directory to get the region servers, and then compare it with the region server list on zookeeper, to find out the dead servers. So if the WAL file system is also cleaned, the cluster will be in trouble too, as it can not find out dead servers, and also will not schedule SCPs. The reason why we use the WAL filesystem to get the region server list is that, we need to use SCP to bring a region online, as well as meta region, so we can not rely on scanning meta region to find out the region server list, otherwise there will be cyclic dependency, this is also the reason why we remove the AssignMetaProcedure, it does not always work. For now, if we only have one meta region, maybe it is possible to do some hacks to find out the region server for meta region, but if later we want to support meta split, things will become much more difficult. But anyway, it will be good if we do not need to rely on WAL filesystem structures when starting up. If anyone has some ideas on how to improve, I'm happy to help reviewing if it actually works. Thanks. > Do not store meta region location on zookeeper > -- > > Key: HBASE-26193 > URL: https://issues.apache.org/jira/browse/HBASE-26193 > Project: HBase > Issue Type: Improvement > Components: meta, Zookeeper >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > > As it breaks one of our design rules > https://hbase.apache.org/book.html#design.invariants.zk.data > We used to think hbase should be recovered automatically when all the data on > zk (except the replication data) are cleared, but obviously, if you clear the > meta region location, the cluster will be in trouble, and need to use > operation tools to recover the cluster. > So here, along with the ConnectionRegistry improvements, we should also > consider move the meta region location off zookeeper. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [hbase] Apache-HBase commented on pull request #3581: HBASE-25849 Backport HBASE-22738 & HBASE-24760 (Fallback feature for RS groups when there are no RS in current group) to branch-1
Apache-HBase commented on pull request #3581: URL: https://github.com/apache/hbase/pull/3581#issuecomment-898201077 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 32s | Docker mode activated. | ||| _ Prechecks _ | | +1 :green_heart: | dupname | 0m 1s | No case conflicting files found. | | +1 :green_heart: | hbaseanti | 0m 0s | Patch does not have any anti-patterns. | | +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. | | +1 :green_heart: | test4tests | 0m 0s | The patch appears to include 3 new or modified test files. | ||| _ branch-1 Compile Tests _ | | +0 :ok: | mvndep | 2m 31s | Maven dependency ordering for branch | | +1 :green_heart: | mvninstall | 8m 9s | branch-1 passed | | +1 :green_heart: | compile | 1m 0s | branch-1 passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | compile | 1m 7s | branch-1 passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | +1 :green_heart: | checkstyle | 1m 53s | branch-1 passed | | +1 :green_heart: | shadedjars | 3m 5s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 56s | branch-1 passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | javadoc | 1m 3s | branch-1 passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | +0 :ok: | spotbugs | 2m 44s | Used deprecated FindBugs config; considering switching to SpotBugs. | | +1 :green_heart: | findbugs | 3m 49s | branch-1 passed | ||| _ Patch Compile Tests _ | | +0 :ok: | mvndep | 0m 17s | Maven dependency ordering for patch | | +1 :green_heart: | mvninstall | 1m 51s | the patch passed | | +1 :green_heart: | compile | 1m 1s | the patch passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | javac | 1m 1s | the patch passed | | +1 :green_heart: | compile | 1m 10s | the patch passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | +1 :green_heart: | javac | 1m 10s | the patch passed | | -1 :x: | checkstyle | 1m 31s | hbase-server: The patch generated 2 new + 24 unchanged - 0 fixed = 26 total (was 24) | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +1 :green_heart: | shadedjars | 2m 50s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | hadoopcheck | 4m 32s | Patch does not cause any errors with Hadoop 2.8.5 2.9.2. | | +1 :green_heart: | javadoc | 0m 45s | the patch passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | javadoc | 1m 0s | the patch passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | -1 :x: | findbugs | 1m 1s | hbase-rsgroup generated 2 new + 0 unchanged - 0 fixed = 2 total (was 0) | ||| _ Other Tests _ | | +1 :green_heart: | unit | 133m 18s | hbase-server in the patch passed. | | +1 :green_heart: | unit | 13m 54s | hbase-rsgroup in the patch passed. | | +1 :green_heart: | asflicense | 0m 58s | The patch does not generate ASF License warnings. | | | | 195m 15s | | | Reason | Tests | |---:|:--| | FindBugs | module:hbase-rsgroup | | | org.apache.hadoop.hbase.rsgroup.RSGroupBasedLoadBalancer.retainAssignment(Map, List) makes inefficient use of keySet iterator instead of entrySet iterator At RSGroupBasedLoadBalancer.java:of keySet iterator instead of entrySet iterator At RSGroupBasedLoadBalancer.java:[line 227] | | | org.apache.hadoop.hbase.rsgroup.RSGroupBasedLoadBalancer.roundRobinAssignment(List, List) makes inefficient use of keySet iterator instead of entrySet iterator At RSGroupBasedLoadBalancer.java:of keySet iterator instead of entrySet iterator At RSGroupBasedLoadBalancer.java:[line 201] | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3581/2/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3581 | | Optional Tests | dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux c9b449f000b7 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /home/jenkins/jenkins-home/workspace/Base-PreCommit-GitHub-PR_PR-3581/out/precommit/personality/provided.sh | | git revision | branch-1 / 75844c8 | | Default Java | Azul Systems, Inc.-1.7.0_272-b10 | | Multi-JDK versions | /usr/lib/jvm/zulu-8-amd64:Azul Systems, Inc.-1.8.0_262-b19 /usr/lib/jvm/zulu-7-amd64:
[jira] [Updated] (HBASE-26143) The default value of 'hbase.hregion.memstore.mslab.indexchunksize.percent' should be 0
[
https://issues.apache.org/jira/browse/HBASE-26143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26143:
-
Summary: The default value of
'hbase.hregion.memstore.mslab.indexchunksize.percent' should be 0 (was: The
default value of 'hbase.hregion.memstore.mslab.indexchunksize.percent' should
depend on MemStore type)
> The default value of 'hbase.hregion.memstore.mslab.indexchunksize.percent'
> should be 0
> --
>
> Key: HBASE-26143
> URL: https://issues.apache.org/jira/browse/HBASE-26143
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.0
>Reporter: chenglei
>Priority: Major
>
> The default value of {{hbase.hregion.memstore.mslab.indexchunksize.percent}}
> introduced by HBASE-24892 is 0.1, but when we use {{DefaultMemStore}} by
> default , which has no IndexChunk and {{ChunkCreator.indexChunksPool}} is
> useless(IndexChunk is only used by CompactingMemStore), so the
> {{hbase.hregion.memstore.mslab.indexchunksize.percent}} should be 0 when we
> using {{DefaultMemStore}} to save memory space. Only when we use
> {{CompactingMemStore}} and {{CellChunkMap}}, it is meaningful to set
> {{hbase.hregion.memstore.mslab.indexchunksize.percent}} by user.
> Howerver, because existing bug in {{ChunkCreator}}, it is depends on
> HBASE-26142
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-26197) Fix some obvious bugs in MultiByteBuff.put
[ https://issues.apache.org/jira/browse/HBASE-26197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenglei updated HBASE-26197: - Summary: Fix some obvious bugs in MultiByteBuff.put (was: Fix obvious bugs in MultiByteBuff.put) > Fix some obvious bugs in MultiByteBuff.put > -- > > Key: HBASE-26197 > URL: https://issues.apache.org/jira/browse/HBASE-26197 > Project: HBase > Issue Type: Bug >Affects Versions: 3.0.0-alpha-1, 2.4.5 >Reporter: chenglei >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-26197) Fix obvious bugs in MultiByteBuff.put
chenglei created HBASE-26197: Summary: Fix obvious bugs in MultiByteBuff.put Key: HBASE-26197 URL: https://issues.apache.org/jira/browse/HBASE-26197 Project: HBase Issue Type: Bug Affects Versions: 2.4.5, 3.0.0-alpha-1 Reporter: chenglei -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [hbase] Apache9 commented on a change in pull request #3566: HBASE-26172 Deprecated MasterRegistry and allow getBootstrapNodes to …
Apache9 commented on a change in pull request #3566:
URL: https://github.com/apache/hbase/pull/3566#discussion_r688283296
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java
##
@@ -308,18 +310,35 @@
*/
private static final long
DEFAULT_REGION_SERVER_RPC_MINIMUM_SCAN_TIME_LIMIT_DELTA = 10;
- /*
+ /**
* Whether to reject rows with size > threshold defined by
* {@link RSRpcServices#BATCH_ROWS_THRESHOLD_NAME}
*/
private static final String REJECT_BATCH_ROWS_OVER_THRESHOLD =
"hbase.rpc.rows.size.threshold.reject";
- /*
+ /**
* Default value of config {@link
RSRpcServices#REJECT_BATCH_ROWS_OVER_THRESHOLD}
*/
private static final boolean DEFAULT_REJECT_BATCH_ROWS_OVER_THRESHOLD =
false;
+ /**
+ * Determine the bootstrap nodes we want to return to the client connection
registry.
+ *
+ * {@link #MASTER}: return masters as bootstrap nodes.
Review comment:
> It appeared that you intended to keep both MasterRegistry,
RpcConnectionRegistry with masters.
Let me explain more...
The issue here, aims to remove MasterRegistry in the future, so
1. Ideally RpcConnectionRegistry should cover what we have in
MasterRegistry, by some configurations at least.
2. We just do not want to support masters any more, so we do not need to
provide configurations at server side, after MasterRegistry is removed, users
can not use masters as connection registry endpoint any more.
But if we go with option 2, maybe it breaks some users, so maybe we should
keep MasterRegistry and do not mark it as deprecated? And then, the
RpcConnectionRegistry should better be renamed to RegionServerRegistry.
So let me conclude, there are 3 options:
1. Deprecated MasterRegistry, plan a removal in 4.0.0, and let
RpcConnectionRegistry still provide the ability to use masters as connection
registry endpoint.
2. Deprecated MasterRegistry, plan a removal in 4.0.0, but still keep
RpcConnectionRegistry only use region servers as connection registry endpoint.
3. Do not deprecated MasterRegistry, rename RpcConnectionRegistry to
RegionServerRegistry.
I do not think we need to rename RpcConnectionRegistry to
RegionServerRegistry if we still want to remove MasterRegistry, so there is
option 4.
Please let me know your choice. But if you want to choose 2 or 3, I think
we'd better post a discussion email to the dev list, as it removes a feature
currently in use, we need to collect more information from users.
Thanks.
--
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: issues-unsubscr...@hbase.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [hbase] Apache9 commented on a change in pull request #3566: HBASE-26172 Deprecated MasterRegistry and allow getBootstrapNodes to …
Apache9 commented on a change in pull request #3566:
URL: https://github.com/apache/hbase/pull/3566#discussion_r688283296
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java
##
@@ -308,18 +310,35 @@
*/
private static final long
DEFAULT_REGION_SERVER_RPC_MINIMUM_SCAN_TIME_LIMIT_DELTA = 10;
- /*
+ /**
* Whether to reject rows with size > threshold defined by
* {@link RSRpcServices#BATCH_ROWS_THRESHOLD_NAME}
*/
private static final String REJECT_BATCH_ROWS_OVER_THRESHOLD =
"hbase.rpc.rows.size.threshold.reject";
- /*
+ /**
* Default value of config {@link
RSRpcServices#REJECT_BATCH_ROWS_OVER_THRESHOLD}
*/
private static final boolean DEFAULT_REJECT_BATCH_ROWS_OVER_THRESHOLD =
false;
+ /**
+ * Determine the bootstrap nodes we want to return to the client connection
registry.
+ *
+ * {@link #MASTER}: return masters as bootstrap nodes.
Review comment:
> It appeared that you intended to keep both MasterRegistry,
RpcConnectionRegistry with masters.
Let me explain more...
The issue here, aims to remove MasterRegistry in the future, so
1. Ideally RpcConnectionRegistry should cover what we have in
MasterRegistry, by some configurations at least.
2. We just do not want to support masters any more, so we do not need to
provide configurations at server side, after MasterRegistry is removed, users
can not use masters as connection registry endpoint any more.
But if we go with option 2, maybe it breaks some users, so maybe we should
keep MasterRegistry and do not mark it as deprecated? And then, the
RpcConnectionRegistry should better be renamed to RegionServerRegistry.
So let me conclude, there are 3 options:
1. Deprecated MasterRegistry, plan a removal in 4.0.0, and let
RpcConnectionRegistry still provide the ability to use masters as connection
registry endpoint.
2. Deprecated MasterRegistry, plan a removal in 4.0.0, but still keep
RpcConnectionRegistry only use region servers as connection registry endpoint.
3. Do not deprecated MasterRegistry, rename RpcConnectionRegistry to
RegionServerRegistry.
I do not think we need to rename RpcConnectionRegistry to
RegionServerRegistry if we still want to remove MasterRegistry, so there is no
option 4.
Please let me know your choice. But if you want to choose 2 or 3, I think
we'd better post a discussion email to the dev list, as it removes a feature
currently in use, we need to collect more information from users.
Thanks.
--
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: issues-unsubscr...@hbase.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
