[GitHub] [hbase] Apache-HBase commented on pull request #3842: HBASE-26421 Use HFileLink file to replace entire file‘s reference whe…
Apache-HBase commented on pull request #3842: URL: https://github.com/apache/hbase/pull/3842#issuecomment-972643464 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 26s | 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. | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 10s | master passed | | +1 :green_heart: | compile | 3m 18s | master passed | | +1 :green_heart: | checkstyle | 1m 11s | master passed | | +1 :green_heart: | spotbugs | 2m 6s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 3m 51s | the patch passed | | +1 :green_heart: | compile | 3m 11s | the patch passed | | +1 :green_heart: | javac | 3m 11s | the patch passed | | +1 :green_heart: | checkstyle | 1m 9s | hbase-server: The patch generated 0 new + 258 unchanged - 2 fixed = 258 total (was 260) | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +1 :green_heart: | hadoopcheck | 19m 27s | Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1. | | +1 :green_heart: | spotbugs | 2m 15s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 17s | The patch does not generate ASF License warnings. | | | | 49m 28s | | | 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-3842/5/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3842 | | Optional Tests | dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux 0594f4b1d1c6 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / 1c47f80d83 | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Max. process+thread count | 96 (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-3842/5/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] sunhelly opened a new pull request #3854: Backport HBASE-26421 Use HFileLink file to replace entire file's refe…
sunhelly opened a new pull request #3854: URL: https://github.com/apache/hbase/pull/3854 …rence when splitting -- 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-23612) Update pom.xml to use another 2.5.0 protoc as external protobuf
[ https://issues.apache.org/jira/browse/HBASE-23612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17445761#comment-17445761 ] Mark Jens commented on HBASE-23612: --- Hi, Is it possible to downport this improvement to branch-2.4 ? Currently it is not possible to build Apache Phoenix on Linux ARM64 ([https://lists.apache.org/thread/kzlyl6d3ynfydo98nko5xvy71h1gjcpy).] Phoenix does not use HBase as a Maven dependency but needs to build it locally with Hadoop3 profile. And since Phoenix supports only HBase 2.x it is not possible to build on ARM64 without manually patching HBase. > Update pom.xml to use another 2.5.0 protoc as external protobuf > --- > > Key: HBASE-23612 > URL: https://issues.apache.org/jira/browse/HBASE-23612 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: zhao bo >Assignee: zhao bo >Priority: Major > Fix For: 3.0.0-alpha-1 > > > Currently, there is no protoc 2.5.0 for release [1]. So we can make a new one > for ARM specific. For make sure that could work on ARM. > We will introduce a new ARM artifact for protoc, group_id is > org.openlabtesting.protobuf .. This is just used for protobuf-maven-plugin to > compile .proto files. As the 3.X version of protoc support ARM already. So > this won't affect the internal protoc usage, which is 3.5.1-1 now. > > [1][https://github.com/protocolbuffers/protobuf/issues/3844#issuecomment-343355946] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [hbase] Apache-HBase commented on pull request #3854: Backport HBASE-26421 Use HFileLink file to replace entire file's refe…
Apache-HBase commented on pull request #3854: URL: https://github.com/apache/hbase/pull/3854#issuecomment-972683982 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 6m 41s | 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. | ||| _ branch-2 Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 18s | branch-2 passed | | +1 :green_heart: | compile | 3m 24s | branch-2 passed | | +1 :green_heart: | checkstyle | 1m 21s | branch-2 passed | | +1 :green_heart: | spotbugs | 2m 14s | branch-2 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 3m 53s | the patch passed | | +1 :green_heart: | compile | 3m 26s | the patch passed | | +1 :green_heart: | javac | 3m 26s | the patch passed | | -0 :warning: | checkstyle | 1m 20s | hbase-server: The patch generated 1 new + 291 unchanged - 2 fixed = 292 total (was 293) | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +1 :green_heart: | hadoopcheck | 13m 51s | Patch does not cause any errors with Hadoop 3.1.2 3.2.1. | | +1 :green_heart: | spotbugs | 2m 21s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 13s | The patch does not generate ASF License warnings. | | | | 51m 33s | | | 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-3854/1/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3854 | | Optional Tests | dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux 7035fb193417 4.15.0-153-generic #160-Ubuntu SMP Thu Jul 29 06:54:29 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | branch-2 / 4a8da47f74 | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | checkstyle | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3854/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt | | Max. process+thread count | 86 (vs. ulimit of 12500) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3854/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 #3842: HBASE-26421 Use HFileLink file to replace entire file‘s reference whe…
Apache-HBase commented on pull request #3842: URL: https://github.com/apache/hbase/pull/3842#issuecomment-972749290 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 8s | 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 | 3m 51s | master passed | | +1 :green_heart: | compile | 1m 1s | master passed | | +1 :green_heart: | shadedjars | 8m 21s | 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 | 3m 54s | 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 14s | 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 | 153m 47s | hbase-server in the patch passed. | | | | 184m 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-3842/5/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3842 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 38149535b1f1 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 / 1c47f80d83 | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3842/5/testReport/ | | Max. process+thread count | 4857 (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-3842/5/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-26460) Close netty channel causes regionserver crash in handleTooBigRequest
[
https://issues.apache.org/jira/browse/HBASE-26460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17445854#comment-17445854
]
Lijin Bin commented on HBASE-26460:
---
I add two config , disable rpc buffer reuse, and encounter Invalid key
length/Invalid value length error, so i guess regionserver receive corrupt
request and the problem is at client code.
{code}
hbase.rpc.server.impl
org.apache.hadoop.hbase.ipc.SimpleRpcServer
hbase.server.allocator.pool.enabled
false
{code}
> Close netty channel causes regionserver crash in handleTooBigRequest
>
>
> Key: HBASE-26460
> URL: https://issues.apache.org/jira/browse/HBASE-26460
> Project: HBase
> Issue Type: Bug
> Components: rpc
>Affects Versions: 3.0.0-alpha-1, 2.0.0
>Reporter: Xiaolin Ha
>Assignee: Xiaolin Ha
>Priority: Critical
>
> In HBASE-26170, I proposed the coredump problem after calling
> handleTooBigRequest, but that issue did not resolve the regionserver crash
> problem, which occurs before the WAL corruption in HBASE-24984.
> After looking through the codes, I think the problem is in CLOSE channel.
> The direct byte buffer used by RPC call request is allocated by Netty, though
> we add a reference count to record when to release the direct byte buffer,
> the byte buffer is managed by Netty actually. It is allocated from Netty
> PoolArena, and is released there.
> When the HBase ipc handler is processing a request, the Netty channel handler
> can process the channel events and message coming back in succession. When
> there is a too big request by NettyRpcFrameDecoder, the channel will be
> closed, and all the resources of the channel will be released, though there
> is HBase ipc handlers using the direct byte buffer to process previous
> requests.
> Netty provides two methods to request the pooled byte buffer, one is through
> the PoolThreadCache, each handler thread owns a private one. Another is
> through PoolArena#allocateNormal. Each ChannelHandler has a local
> PoolThreadCache.
> When a new Netty channel is created, a new ChannelHandler instance is
> created.
> And when a channel is closed, the relevant channel handler will be removed
> from the pipeline. I found this annotation in the Channel class of Netty,
> {code:java}
> It is important to call close() or close(ChannelPromise) to release all
> resources once you are done with the Channel. This ensures all resources are
> released in a proper way, i.e. filehandles. {code}
> And when channel handler is removed in ByteToMessageDecoder#handlerRemoved,
> it will release the byte buffer,
> {code:java}
> @Override
> public final void handlerRemoved(ChannelHandlerContext ctx) throws Exception {
> if (decodeState == STATE_CALLING_CHILD_DECODE) {
> decodeState = STATE_HANDLER_REMOVED_PENDING;
> return;
> }
> ByteBuf buf = cumulation;
> if (buf != null) {
> // Directly set this to null so we are sure we not access it in any
> other method here anymore.
> cumulation = null;
> int readable = buf.readableBytes();
> if (readable > 0) {
> ByteBuf bytes = buf.readBytes(readable);
> buf.release();
> ctx.fireChannelRead(bytes);
> } else {
> buf.release();
> }
> ... {code}
> We should not close the channel when encountering too big request, I think it
> should just skip the bytes like that in LengthFieldBasedFrameDecoder.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is used.
chenglei created HBASE-26465: Summary: MemStoreLAB may be released early when its SegmentScanner is used. Key: HBASE-26465 URL: https://issues.apache.org/jira/browse/HBASE-26465 Project: HBase Issue Type: Bug Reporter: chenglei -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is used.
[ https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenglei updated HBASE-26465: - Affects Version/s: 2.4.8 3.0.0-alpha-1 > MemStoreLAB may be released early when its SegmentScanner is used. > --- > > Key: HBASE-26465 > URL: https://issues.apache.org/jira/browse/HBASE-26465 > Project: HBase > Issue Type: Bug >Affects Versions: 3.0.0-alpha-1, 2.4.8 >Reporter: chenglei >Priority: Critical > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [hbase] Apache-HBase commented on pull request #3854: Backport HBASE-26421 Use HFileLink file to replace entire file's refe…
Apache-HBase commented on pull request #3854: URL: https://github.com/apache/hbase/pull/3854#issuecomment-972779168 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 33s | Docker mode activated. | | -0 :warning: | yetus | 0m 7s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ branch-2 Compile Tests _ | | +1 :green_heart: | mvninstall | 3m 55s | branch-2 passed | | +1 :green_heart: | compile | 0m 56s | branch-2 passed | | +1 :green_heart: | shadedjars | 6m 33s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 40s | branch-2 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 3m 34s | the patch passed | | +1 :green_heart: | compile | 1m 0s | the patch passed | | +1 :green_heart: | javac | 1m 0s | the patch passed | | +1 :green_heart: | shadedjars | 6m 32s | 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 | 146m 57s | hbase-server in the patch passed. | | | | 173m 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-3854/1/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3854 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 8f767adf1e6b 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | branch-2 / 4a8da47f74 | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3854/1/testReport/ | | Max. process+thread count | 3960 (vs. ulimit of 12500) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3854/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-26465) MemStoreLAB may be released early when its SegmentScanner is used.
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description: HBASE-26144 moved {{MemStore.clearSnapshot}} out of
{{HStore#lock}}, but I find that because {{MemStore.clearSnapshot}} closing
{{DefaultMemStore#snapshot}}, which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore.clearSnapshot}} execute conurrently,
> MemStoreLAB may be released early when its SegmentScanner is used.
> ---
>
> Key: HBASE-26465
> URL: https://issues.apache.org/jira/browse/HBASE-26465
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.8
>Reporter: chenglei
>Priority: Critical
>
> HBASE-26144 moved {{MemStore.clearSnapshot}} out of {{HStore#lock}}, but I
> find that because {{MemStore.clearSnapshot}} closing
> {{DefaultMemStore#snapshot}}, which may be used by
> {{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
> {{MemStore.clearSnapshot}} execute conurrently,
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [hbase] Apache-HBase commented on pull request #3842: HBASE-26421 Use HFileLink file to replace entire file‘s reference whe…
Apache-HBase commented on pull request #3842: URL: https://github.com/apache/hbase/pull/3842#issuecomment-972823548 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 6m 44s | 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 59s | master passed | | +1 :green_heart: | compile | 1m 40s | master passed | | +1 :green_heart: | shadedjars | 10m 32s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 54s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 6m 6s | the patch passed | | +1 :green_heart: | compile | 1m 37s | the patch passed | | +1 :green_heart: | javac | 1m 37s | the patch passed | | +1 :green_heart: | shadedjars | 10m 48s | 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 | 241m 14s | hbase-server in the patch passed. | | | | 288m 28s | | | 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-3842/5/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3842 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux f77dc3d10b6b 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 / 1c47f80d83 | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3842/5/testReport/ | | Max. process+thread count | 2944 (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-3842/5/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-26465) MemStoreLAB may be released early when its SegmentScanner is used.
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description: HBASE-26144 moved {{MemStore.clearSnapshot}} out of
{{HStore#lock}}, but I find that because {{MemStore.clearSnapshot}} closing
{{DefaultMemStore#snapshot}}, which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore.clearSnapshot}} execute conurrently, {{MemStoreLAB}} used by
{{MemStore.clearSnapshot}} may be released early when its {{SegmentScanner }}
is scanning. (was: HBASE-26144 moved {{MemStore.clearSnapshot}} out of
{{HStore#lock}}, but I find that because {{MemStore.clearSnapshot}} closing
{{DefaultMemStore#snapshot}}, which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore.clearSnapshot}} execute conurrently, )
> MemStoreLAB may be released early when its SegmentScanner is used.
> ---
>
> Key: HBASE-26465
> URL: https://issues.apache.org/jira/browse/HBASE-26465
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.8
>Reporter: chenglei
>Priority: Critical
>
> HBASE-26144 moved {{MemStore.clearSnapshot}} out of {{HStore#lock}}, but I
> find that because {{MemStore.clearSnapshot}} closing
> {{DefaultMemStore#snapshot}}, which may be used by
> {{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
> {{MemStore.clearSnapshot}} execute conurrently, {{MemStoreLAB}} used by
> {{MemStore.clearSnapshot}} may be released early when its {{SegmentScanner
> }} is scanning.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Summary: MemStoreLAB may be released early when its SegmentScanner is
scanning (was: MemStoreLAB may be released early when its SegmentScanner is
used. )
> MemStoreLAB may be released early when its SegmentScanner is scanning
> -
>
> Key: HBASE-26465
> URL: https://issues.apache.org/jira/browse/HBASE-26465
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.8
>Reporter: chenglei
>Priority: Critical
>
> HBASE-26144 moved {{MemStore.clearSnapshot}} out of {{HStore#lock}}, but I
> find that because {{MemStore.clearSnapshot}} closing
> {{DefaultMemStore#snapshot}}, which may be used by
> {{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
> {{MemStore.clearSnapshot}} execute conurrently, {{MemStoreLAB}} used by
> {{MemStore.clearSnapshot}} may be released early when its {{SegmentScanner
> }} is scanning.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description: HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock
of {{HStore#lock}}, but I find that because {{MemStore.clearSnapshot}} closing
{{DefaultMemStore#snapshot}}, which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore.clearSnapshot}} execute conurrently, {{MemStoreLAB}} used by
{{MemStore.clearSnapshot}} may be released early when its {{SegmentScanner }}
is scanning. (was: HBASE-26144 moved {{MemStore.clearSnapshot}} out of
{{HStore#lock}}, but I find that because {{MemStore.clearSnapshot}} closing
{{DefaultMemStore#snapshot}}, which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore.clearSnapshot}} execute conurrently, {{MemStoreLAB}} used by
{{MemStore.clearSnapshot}} may be released early when its {{SegmentScanner }}
is scanning.)
> MemStoreLAB may be released early when its SegmentScanner is scanning
> -
>
> Key: HBASE-26465
> URL: https://issues.apache.org/jira/browse/HBASE-26465
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.8
>Reporter: chenglei
>Priority: Critical
>
> HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
> {{HStore#lock}}, but I find that because {{MemStore.clearSnapshot}} closing
> {{DefaultMemStore#snapshot}}, which may be used by
> {{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
> {{MemStore.clearSnapshot}} execute conurrently, {{MemStoreLAB}} used by
> {{MemStore.clearSnapshot}} may be released early when its {{SegmentScanner
> }} is scanning.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore.clearSnapshot}} execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner
}} is scanning.
Considering follow thread
was:HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore.clearSnapshot}} execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner
}} is scanning.
> MemStoreLAB may be released early when its SegmentScanner is scanning
> -
>
> Key: HBASE-26465
> URL: https://issues.apache.org/jira/browse/HBASE-26465
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.8
>Reporter: chenglei
>Priority: Critical
>
> HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
> {{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
> {{DefaultMemStore#snapshot}} which may be used by
> {{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
> {{MemStore.clearSnapshot}} execute conurrently, {{MemStoreLAB}} used by
> {{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner
> }} is scanning.
> Considering follow thread
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description: HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock
of {{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore.clearSnapshot}} execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner
}} is scanning. (was: HBASE-26144 moved {{MemStore.clearSnapshot}} out of
write lock of {{HStore#lock}}, but I find that because
{{MemStore.clearSnapshot}} closing {{DefaultMemStore#snapshot}}, which may be
used by {{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}}
and {{MemStore.clearSnapshot}} execute conurrently, {{MemStoreLAB}} used by
{{MemStore.clearSnapshot}} may be released early when its {{SegmentScanner }}
is scanning.)
> MemStoreLAB may be released early when its SegmentScanner is scanning
> -
>
> Key: HBASE-26465
> URL: https://issues.apache.org/jira/browse/HBASE-26465
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.8
>Reporter: chenglei
>Priority: Critical
>
> HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
> {{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
> {{DefaultMemStore#snapshot}} which may be used by
> {{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
> {{MemStore.clearSnapshot}} execute conurrently, {{MemStoreLAB}} used by
> {{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner
> }} is scanning.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [hbase] Apache-HBase commented on pull request #3854: Backport HBASE-26421 Use HFileLink file to replace entire file's refe…
Apache-HBase commented on pull request #3854: URL: https://github.com/apache/hbase/pull/3854#issuecomment-972827336 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 6m 44s | Docker mode activated. | | -0 :warning: | yetus | 0m 7s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck | ||| _ Prechecks _ | ||| _ branch-2 Compile Tests _ | | +1 :green_heart: | mvninstall | 5m 7s | branch-2 passed | | +1 :green_heart: | compile | 1m 13s | branch-2 passed | | +1 :green_heart: | shadedjars | 8m 6s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 43s | branch-2 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 48s | 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 0s | 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 | 204m 37s | hbase-server in the patch passed. | | | | 243m 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-3854/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3854 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 045d5d78f7b7 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 | branch-2 / 4a8da47f74 | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3854/1/testReport/ | | Max. process+thread count | 2693 (vs. ulimit of 12500) | | modules | C: hbase-server U: hbase-server | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3854/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-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner
}} is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
3.The scan thread starts and stopping after
{{DefaultMemStore#getSnapshotSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
are recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunk}}s in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunk}}s
may
be overwritten by other write threads, which may cause serious problem.
was:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore.clearSnapshot}} execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner
}} is scanning.
Considering follow thread
> MemStoreLAB may be released early when its SegmentScanner is scanning
> -
>
> Key: HBASE-26465
> URL: https://issues.apache.org/jira/browse/HBASE-26465
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.8
>Reporter: chenglei
>Priority: Critical
>
> HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
> {{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
> {{DefaultMemStore#snapshot}} which may be used by
> {{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
> {{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
> {{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner
> }} is scanning.
> Considering follow thread sequences:
> 1.The flush thread starts {{DefaultMemStore}} flushing after some cells have
> be added to {{DefaultMemStore}}.
> 2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
>{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
> 3.The scan thread starts and stopping after
> {{DefaultMemStore#getSnapshotSegments}} in
>{{DefaultMemStore#getScanners}},here the scan thread gets the
> {{DefaultMemStore#snapshot}} which is created by the flush thread.
> 4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
> {{DefaultMemStore#snapshot}},because the reference count of the corresponding
>{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
> are recycled.
> 5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
> {{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
>reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunk}}s
> in corresponding {{MemStoreLABImpl}} are recycled by step 4, and these
> {{Chunk}}s may
>be overwritten by other write threads, which may cause serious problem.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner
}} is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
3.The scan thread starts and stopping after
{{DefaultMemStore#getSnapshotSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
are recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunk}}s in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunk}}s
may
be overwritten by other write threads, which may cause serious problem.
was:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner
}} is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
3.The scan thread starts and stopping after
{{DefaultMemStore#getSnapshotSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
are recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunk}}s in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunk}}s
may
be overwritten by other write threads, which may cause serious problem.
> MemStoreLAB may be released early when its SegmentScanner is scanning
> -
>
> Key: HBASE-26465
> URL: https://issues.apache.org/jira/browse/HBASE-26465
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.8
>Reporter: chenglei
>Priority: Critical
>
> HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
> {{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
> {{DefaultMemStore#snapshot}} which may be used by
> {{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
> {{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
> {{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner
> }} is scanning.
> Considering follow thread sequences:
> 1.The flush thread starts {{DefaultMemStore}} flushing after some cells have
> be added to {{DefaultMemStore}}.
> 2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
>{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
> 3.The scan thread starts and stopping after
> {{DefaultMemStore#getSnapshotSegments}} in
>{{DefaultMemStore#getScanners}},here the scan thread gets the
> {{DefaultMemStore#snapshot}} which is created by the flush thread.
> 4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
> {{DefaultMemStore#snapshot}},because the reference count of the corresponding
>{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
> are re
[jira] [Updated] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
3.The scan thread starts and stopping after
{{DefaultMemStore#getSnapshotSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
are recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunk}}s in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunk}}s
may
be overwritten by other write threads, which may cause serious problem.
was:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner
}} is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
3.The scan thread starts and stopping after
{{DefaultMemStore#getSnapshotSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
are recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunk}}s in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunk}}s
may
be overwritten by other write threads, which may cause serious problem.
> MemStoreLAB may be released early when its SegmentScanner is scanning
> -
>
> Key: HBASE-26465
> URL: https://issues.apache.org/jira/browse/HBASE-26465
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.8
>Reporter: chenglei
>Priority: Critical
>
> HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
> {{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
> {{DefaultMemStore#snapshot}} which may be used by
> {{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
> {{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
> {{DefaultMemStore#snapshot}} may be released early when its
> {{SegmentScanner}} is scanning.
> Considering follow thread sequences:
> 1.The flush thread starts {{DefaultMemStore}} flushing after some cells have
> be added to {{DefaultMemStore}}.
> 2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
>{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
> 3.The scan thread starts and stopping after
> {{DefaultMemStore#getSnapshotSegments}} in
>{{DefaultMemStore#getScanners}},here the scan thread gets the
> {{DefaultMemStore#snapshot}} which is created by the flush thread.
> 4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
> {{DefaultMemStore#snapshot}},because the reference count of the corresponding
>{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
> are
[jira] [Updated] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
3.The scan thread starts and stopping after
{{DefaultMemStore#getSnapshotSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
are recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunks}} in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunk}}s
may
be overwritten by other write threads, which may cause serious problem.
was:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
3.The scan thread starts and stopping after
{{DefaultMemStore#getSnapshotSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
are recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunk}}s in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunk}}s
may
be overwritten by other write threads, which may cause serious problem.
> MemStoreLAB may be released early when its SegmentScanner is scanning
> -
>
> Key: HBASE-26465
> URL: https://issues.apache.org/jira/browse/HBASE-26465
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.8
>Reporter: chenglei
>Priority: Critical
>
> HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
> {{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
> {{DefaultMemStore#snapshot}} which may be used by
> {{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
> {{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
> {{DefaultMemStore#snapshot}} may be released early when its
> {{SegmentScanner}} is scanning.
> Considering follow thread sequences:
> 1.The flush thread starts {{DefaultMemStore}} flushing after some cells have
> be added to {{DefaultMemStore}}.
> 2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
>{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
> 3.The scan thread starts and stopping after
> {{DefaultMemStore#getSnapshotSegments}} in
>{{DefaultMemStore#getScanners}},here the scan thread gets the
> {{DefaultMemStore#snapshot}} which is created by the flush thread.
> 4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
> {{DefaultMemStore#snapshot}},because the reference count of the corresponding
>{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
> are
[jira] [Updated] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
3.The scan thread starts and stopping after
{{DefaultMemStore#getSnapshotSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
are recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunks}} in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunks}}
may
be overwritten by other write threads, which may cause serious problem.
was:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
3.The scan thread starts and stopping after
{{DefaultMemStore#getSnapshotSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
are recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunks}} in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunk}}s
may
be overwritten by other write threads, which may cause serious problem.
> MemStoreLAB may be released early when its SegmentScanner is scanning
> -
>
> Key: HBASE-26465
> URL: https://issues.apache.org/jira/browse/HBASE-26465
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.8
>Reporter: chenglei
>Priority: Critical
>
> HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
> {{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
> {{DefaultMemStore#snapshot}} which may be used by
> {{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
> {{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
> {{DefaultMemStore#snapshot}} may be released early when its
> {{SegmentScanner}} is scanning.
> Considering follow thread sequences:
> 1.The flush thread starts {{DefaultMemStore}} flushing after some cells have
> be added to {{DefaultMemStore}}.
> 2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
>{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
> 3.The scan thread starts and stopping after
> {{DefaultMemStore#getSnapshotSegments}} in
>{{DefaultMemStore#getScanners}},here the scan thread gets the
> {{DefaultMemStore#snapshot}} which is created by the flush thread.
> 4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
> {{DefaultMemStore#snapshot}},because the reference count of the corresponding
>{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
> are
[jira] [Created] (HBASE-26466) Immutable timeseries usecase - Create new region rather than split existing one
Viraj Jasani created HBASE-26466:
Summary: Immutable timeseries usecase - Create new region rather
than split existing one
Key: HBASE-26466
URL: https://issues.apache.org/jira/browse/HBASE-26466
Project: HBase
Issue Type: Brainstorming
Reporter: Viraj Jasani
For insertion of immutable data usecase (specifically time-series data), region
split mechanism doesn't seem to provide better availability when ingestion rate
is very high. When we ingest lot of data, the region split policy tries to
split the given hot region based on the size (either size of all stores
combined or size of any single store exceeding max file size configured) if we
consider default {_}SteppingSplitPolicy{_}. The latest hot regions tend to
receive all latest inserts. When the region is split, the first half of the
region (say daughterA) stays on the same server whereas the second half
(daughterB) region – likely to become another hot region because all new latest
updates come to second half region in the sequential write fashion – is moved
out to other servers in the cluster. Hence, once new daughter region is
created, client traffic will be redirected to another server. Client requests
will be piled up when region split is triggered till new daughters come alive
and once done, client will have to request meta for updated daughter region and
redirect traffic to new server.
If we could have configurable region creation strategy that 1) keeps the split
disabled for the given table, and 2) create new region dynamically with
lexicographically higher start key on the same server and update it's own
region boundary, the client will have to look up meta once and continue
ingestion without any degraded SLA caused by region split transitions.
Note: region split might also encounter some complications, requiring the
procedure to be rolled back from some step, or continue with internal retries,
eventually further delaying the ingestion from clients.
There are some complications around updating live region's start and end keys
as this key range is immutable. We could brainstorm ideas around making them
optionally mutable and any issues around them. For instance, client might
continue writing data to the region with updated end key but writes will fail
and hence, they will lookup in meta for updated key-space range of the table.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [hbase] sunhelly merged pull request #3842: HBASE-26421 Use HFileLink file to replace entire file‘s reference whe…
sunhelly merged pull request #3842: URL: https://github.com/apache/hbase/pull/3842 -- 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 merged pull request #3854: Backport HBASE-26421 Use HFileLink file to replace entire file's refe…
sunhelly merged pull request #3854: URL: https://github.com/apache/hbase/pull/3854 -- 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 #3845: HBASE-26454 CreateTableProcedure still relies on temp dir and renames…
wchevreuil commented on a change in pull request #3845:
URL: https://github.com/apache/hbase/pull/3845#discussion_r752265249
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/SnapshotScannerHDFSAclHelper.java
##
@@ -474,8 +474,8 @@ void createTableDirectories(TableName tableName) throws
IOException {
*/
List getTableRootPaths(TableName tableName, boolean
includeSnapshotPath)
throws IOException {
-List paths = Lists.newArrayList(pathHelper.getTmpTableDir(tableName),
Review comment:
Found out this was creating table tmp dir on
CreateTableProcedure.CREATE_TABLE_POST_OPERATION when ACL is enabled,
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/SnapshotScannerHDFSAclHelper.java
##
@@ -474,8 +474,8 @@ void createTableDirectories(TableName tableName) throws
IOException {
*/
List getTableRootPaths(TableName tableName, boolean
includeSnapshotPath)
throws IOException {
-List paths = Lists.newArrayList(pathHelper.getTmpTableDir(tableName),
Review comment:
Found out this was creating table tmp dir on
CreateTableProcedure.CREATE_TABLE_POST_OPERATION when ACL is enabled.
--
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-26421) Use HFileLink file to replace entire file‘s reference when splitting
[ https://issues.apache.org/jira/browse/HBASE-26421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha resolved HBASE-26421. Fix Version/s: 2.5.0 3.0.0-alpha-2 Resolution: Fixed Merged to master, branch-2 and branch-2.4. Thanks [~zhangduo] for reviewing. > Use HFileLink file to replace entire file‘s reference when splitting > > > Key: HBASE-26421 > URL: https://issues.apache.org/jira/browse/HBASE-26421 > Project: HBase > Issue Type: Sub-task >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > Fix For: 2.5.0, 3.0.0-alpha-2 > > > ++When splitting store files, if a file should be owned by only one child > region, then there will be an entire file's reference in the child region. We > can use HFileLink files, just like those in snapshot tables, to replace the > reference files that refer to entire files. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (HBASE-26422) Support priority select reference files for compaction of stripe store engine
[ https://issues.apache.org/jira/browse/HBASE-26422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-26422: --- Summary: Support priority select reference files for compaction of stripe store engine (was: Support only select reference files for the compaction after split) > Support priority select reference files for compaction of stripe store engine > - > > Key: HBASE-26422 > URL: https://issues.apache.org/jira/browse/HBASE-26422 > Project: HBase > Issue Type: Sub-task >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > > The reference files are those with these patterns, . > and =-.. > We can compact these reference files in the first compaction after splitting, > instead of a major compaction. > Then when the region only has normal hfiles and HFileLink files, it can be > splitted once more. > From the overall perspective, it can reduce compaction IOs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (HBASE-26423) Support move linked data files between regions of the same table when compacting in stripe store engine
[ https://issues.apache.org/jira/browse/HBASE-26423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-26423: --- Summary: Support move linked data files between regions of the same table when compacting in stripe store engine (was: Support move linked data files between regions of the same table when compacting) > Support move linked data files between regions of the same table when > compacting in stripe store engine > --- > > Key: HBASE-26423 > URL: https://issues.apache.org/jira/browse/HBASE-26423 > Project: HBase > Issue Type: Sub-task >Reporter: Xiaolin Ha >Priority: Minor > > There are two important contents for this issue, > # must add reference files for moved data files in a dependent directory > which will be looked through to find out which region the data file is > currently in; > # for HFileLinks in the same table of snapshot table, must support these > links to add more locations according to the move info. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [hbase] Apache-HBase commented on pull request #3845: HBASE-26454 CreateTableProcedure still relies on temp dir and renames…
Apache-HBase commented on pull request #3845: URL: https://github.com/apache/hbase/pull/3845#issuecomment-972931504 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 5s | 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-26067 Compile Tests _ | | +1 :green_heart: | mvninstall | 3m 58s | HBASE-26067 passed | | +1 :green_heart: | compile | 3m 11s | HBASE-26067 passed | | +1 :green_heart: | checkstyle | 1m 3s | HBASE-26067 passed | | +1 :green_heart: | spotbugs | 2m 8s | HBASE-26067 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 3m 46s | the patch passed | | +1 :green_heart: | compile | 3m 10s | the patch passed | | +1 :green_heart: | javac | 3m 10s | the patch passed | | -0 :warning: | checkstyle | 1m 6s | hbase-server: The patch generated 13 new + 0 unchanged - 0 fixed = 13 total (was 0) | | -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 | 19m 24s | Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1. | | +1 :green_heart: | spotbugs | 2m 17s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 14s | The patch does not generate ASF License warnings. | | | | 49m 26s | | | 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-3845/4/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3845 | | Optional Tests | dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux 5ad8675cd2bb 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-26067 / 36b6088a26 | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | checkstyle | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3845/4/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt | | whitespace | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3845/4/artifact/yetus-general-check/output/whitespace-eol.txt | | Max. process+thread count | 96 (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-3845/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] [Updated] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
3.The scan thread starts and stopping after
{{DefaultMemStore#getSnapshotSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
are recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunks}} in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunks}}
may
be overwritten by other write threads, which may cause serious problem.
I simulate above case in my PR, and my Fix in the PR is as following:
1.Moving {{MemStore.clearSnapshot}} back under write lock of {{HStore#lock}},
because {{DefaultMemStore#getScanners}} is protected under the read lock of
{{HStore#lock}}, so {{DefaultMemStore#getScanners}} and
{{DefaultMemStore#clearSnapshot}} could not execute concurrently.
2. Introducing {{RefCnt}} into {{MemStoreLABImpl}} to replace old reference
count, so checking and increasing or decreasing is done in atomicity and if
there is illegal state in reference count, it would throw exception rather
than corrupt data.
was:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
3.The scan thread starts and stopping after
{{DefaultMemStore#getSnapshotSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
are recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunks}} in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunks}}
may
be overwritten by other write threads, which may cause serious problem.
> MemStoreLAB may be released early when its SegmentScanner is scanning
> -
>
> Key: HBASE-26465
> URL: https://issues.apache.org/jira/browse/HBASE-26465
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.8
>Reporter: chenglei
>Priority: Critical
>
> HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
> {{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
> {{DefaultMemStore#snapshot}} which may be used by
> {{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
> {{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
> {{DefaultMemStore#snapshot}} may be released early when its
> {{SegmentScanner}} is scanning.
> Considering follow thread sequences:
> 1.The flush thread starts {{DefaultMemStore}} flushing after some cells have
> be added to {{DefaultMemStore}}.
> 2.The flush thr
[jira] [Updated] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
3.The scan thread starts and stopping after
{{DefaultMemStore.snapshot.getAllSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}} are
recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunks}} in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunks}}
may be overwritten by other write threads, which may cause serious problem.
I simulate above case in my PR, and my Fix in the PR is as following:
1.Moving {{MemStore.clearSnapshot}} back under write lock of {{HStore#lock}},
because {{DefaultMemStore#getScanners}} is protected under the read lock of
{{HStore#lock}}, so {{DefaultMemStore#getScanners}} and
{{DefaultMemStore#clearSnapshot}} could not execute concurrently.
2. Introducing {{RefCnt}} into {{MemStoreLABImpl}} to replace old reference
count, so checking and increasing or decreasing is done in atomicity and if
there is illegal state in reference count, it would throw exception rather
than corrupt data.
was:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
3.The scan thread starts and stopping after
{{DefaultMemStore#getSnapshotSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
are recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunks}} in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunks}}
may
be overwritten by other write threads, which may cause serious problem.
I simulate above case in my PR, and my Fix in the PR is as following:
1.Moving {{MemStore.clearSnapshot}} back under write lock of {{HStore#lock}},
because {{DefaultMemStore#getScanners}} is protected under the read lock of
{{HStore#lock}}, so {{DefaultMemStore#getScanners}} and
{{DefaultMemStore#clearSnapshot}} could not execute concurrently.
2. Introducing {{RefCnt}} into {{MemStoreLABImpl}} to replace old reference
count, so checking and increasing or decreasing is done in atomicity and if
there is illegal state in reference count, it would throw exception rather
than corrupt data.
> MemStoreLAB may be released early when its SegmentScanner is scanning
> -
>
> Key: HBASE-26465
> URL: https://issues.apache.org/jira/browse/HBASE-26465
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.8
>Reporter: chenglei
>Priority: Critical
>
> H
[GitHub] [hbase] sunhelly opened a new pull request #3855: HBASE-26422 Support priority select reference files for compaction of…
sunhelly opened a new pull request #3855: URL: https://github.com/apache/hbase/pull/3855 … stripe store engine -- 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] [Assigned] (HBASE-26423) Support move linked data files between regions of the same table in StripeCompactionPolicy
[ https://issues.apache.org/jira/browse/HBASE-26423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha reassigned HBASE-26423: -- Assignee: Xiaolin Ha > Support move linked data files between regions of the same table in > StripeCompactionPolicy > -- > > Key: HBASE-26423 > URL: https://issues.apache.org/jira/browse/HBASE-26423 > Project: HBase > Issue Type: Sub-task >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Minor > > There are two important contents for this issue, > # must add reference files for moved data files in a dependent directory > which will be looked through to find out which region the data file is > currently in; > # for HFileLinks in the same table of snapshot table, must support these > links to add more locations according to the move info. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (HBASE-26423) Support move linked data files between regions of the same table in StripeCompactionPolicy
[ https://issues.apache.org/jira/browse/HBASE-26423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-26423: --- Summary: Support move linked data files between regions of the same table in StripeCompactionPolicy (was: Support move linked data files between regions of the same table when compacting in stripe store engine) > Support move linked data files between regions of the same table in > StripeCompactionPolicy > -- > > Key: HBASE-26423 > URL: https://issues.apache.org/jira/browse/HBASE-26423 > Project: HBase > Issue Type: Sub-task >Reporter: Xiaolin Ha >Priority: Minor > > There are two important contents for this issue, > # must add reference files for moved data files in a dependent directory > which will be looked through to find out which region the data file is > currently in; > # for HFileLinks in the same table of snapshot table, must support these > links to add more locations according to the move info. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (HBASE-26422) Support priority select reference files in StripeCompactionPolicy
[ https://issues.apache.org/jira/browse/HBASE-26422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-26422: --- Summary: Support priority select reference files in StripeCompactionPolicy (was: Support priority select reference files for compaction of stripe store engine) > Support priority select reference files in StripeCompactionPolicy > - > > Key: HBASE-26422 > URL: https://issues.apache.org/jira/browse/HBASE-26422 > Project: HBase > Issue Type: Sub-task >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > > The reference files are those with these patterns, . > and =-.. > We can compact these reference files in the first compaction after splitting, > instead of a major compaction. > Then when the region only has normal hfiles and HFileLink files, it can be > splitted once more. > From the overall perspective, it can reduce compaction IOs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [hbase] Apache9 commented on a change in pull request #3803: HBASE-26304: Reflect out of band locality improvements in metrics and balancer
Apache9 commented on a change in pull request #3803:
URL: https://github.com/apache/hbase/pull/3803#discussion_r752329695
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/InputStreamBlockDistribution.java
##
@@ -0,0 +1,143 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ * http://www.apache.org/licenses/LICENSE-2.0
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.hadoop.hbase.regionserver;
+
+import com.google.errorprone.annotations.RestrictedApi;
+import java.io.IOException;
+import org.apache.hadoop.conf.Configuration;
+import org.apache.hadoop.fs.FSDataInputStream;
+import org.apache.hadoop.hbase.HDFSBlocksDistribution;
+import org.apache.hadoop.hbase.io.FileLink;
+import org.apache.hadoop.hbase.util.EnvironmentEdgeManager;
+import org.apache.hadoop.hbase.util.FSUtils;
+import org.apache.hadoop.hdfs.client.HdfsDataInputStream;
+import org.apache.yetus.audience.InterfaceAudience;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+/**
+ * Computes the HDFSBlockDistribution for a file based on the underlying
located blocks
+ * for an HdfsDataInputStream reading that file. This computation may involve
a call to
+ * the namenode, so the value is cached based on
+ * {@link #HBASE_LOCALITY_INPUTSTREAM_DERIVE_CACHE_PERIOD}.
+ */
+@InterfaceAudience.Private
+public class InputStreamBlockDistribution {
+ private static final Logger LOG =
LoggerFactory.getLogger(InputStreamBlockDistribution.class);
+
+ private static final String HBASE_LOCALITY_INPUTSTREAM_DERIVE_ENABLED =
+"hbase.locality.inputstream.derive.enabled";
+ private static final boolean
DEFAULT_HBASE_LOCALITY_INPUTSTREAM_DERIVE_ENABLED = false;
+
+ private static final String HBASE_LOCALITY_INPUTSTREAM_DERIVE_CACHE_PERIOD =
+"hbase.locality.inputstream.derive.cache.period";
+ private static final int
DEFAULT_HBASE_LOCALITY_INPUTSTREAM_DERIVE_CACHE_PERIOD = 60_000;
+
+ private final FSDataInputStream stream;
+ private final StoreFileInfo fileInfo;
+ private final int cachePeriodMs;
+
+ private HDFSBlocksDistribution hdfsBlocksDistribution;
+ private long lastCachedAt;
+ private boolean streamUnsupported;
+
+ public InputStreamBlockDistribution(FSDataInputStream stream, StoreFileInfo
fileInfo) {
+this.stream = stream;
Review comment:
So where is the stream constructed? What if it is closed but we still
want to compute locality? Is this possible?
--
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 #3641: HBASE-26006 Update ref guide about the 2.4.x release line
Apache9 commented on pull request #3641: URL: https://github.com/apache/hbase/pull/3641#issuecomment-972958557 Any updates here @apurtell ? I think we need to add the 2.4.x release line information to our ref guide as now it is the only active branch for 2.x... -- 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 #3855: HBASE-26422 Support priority select reference files in StripeCompactionPolicy
Apache-HBase commented on pull request #3855: URL: https://github.com/apache/hbase/pull/3855#issuecomment-972989116 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 1s | 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-25302 Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 33s | HBASE-25302 passed | | +1 :green_heart: | compile | 3m 22s | HBASE-25302 passed | | +1 :green_heart: | checkstyle | 1m 13s | HBASE-25302 passed | | +1 :green_heart: | spotbugs | 2m 13s | HBASE-25302 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 14s | the patch passed | | +1 :green_heart: | compile | 3m 19s | the patch passed | | +1 :green_heart: | javac | 3m 19s | the patch passed | | -0 :warning: | checkstyle | 1m 13s | hbase-server: The patch generated 1 new + 23 unchanged - 1 fixed = 24 total (was 24) | | -0 :warning: | whitespace | 0m 0s | The patch has 3 line(s) that end in whitespace. Use git apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply | | +1 :green_heart: | hadoopcheck | 21m 27s | Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1. | | +1 :green_heart: | spotbugs | 2m 23s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 14s | The patch does not generate ASF License warnings. | | | | 54m 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-3855/1/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3855 | | Optional Tests | dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux 02011bae5376 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-25302 / b2571df7ae | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | checkstyle | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3855/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt | | whitespace | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3855/1/artifact/yetus-general-check/output/whitespace-eol.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-3855/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] [Commented] (HBASE-26458) Value of hbase.master.snapshot.ttl is not used
[
https://issues.apache.org/jira/browse/HBASE-26458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17446055#comment-17446055
]
Joel Swiatek commented on HBASE-26458:
--
After more discussion on the PR https://github.com/apache/hbase/pull/3852 and
offline, we are going to document existing behavior for master and branch-2 and
apply a code fix to branch-1.
The code fixes for master and branch-2 require changing behavior of protobufs,
which is incompatible and can create inconsistent RPC payloads during rolling
upgrades.
> Value of hbase.master.snapshot.ttl is not used
> --
>
> Key: HBASE-26458
> URL: https://issues.apache.org/jira/browse/HBASE-26458
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Affects Versions: 1.7.1, 2.4.8
>Reporter: Joel Swiatek
>Assignee: Joel Swiatek
>Priority: Minor
> Fix For: 1.7.1, 2.4.8
>
> Attachments:
> branch-1-0001-HBASE-22458-Add-UNSET_SNAPSHOT_PROP-and-fix-TTL-defa.patch,
> branch-2-0001-HBASE-22458-Add-UNSET_SNAPSHOT_PROP-and-fix-TTL-defa.patch,
> master-0001-HBASE-22458-Add-UNSET_SNAPSHOT_PROP-and-fix-TTL-defa.patch
>
> Original Estimate: 120h
> Remaining Estimate: 120h
>
> When creating a snapshot, users can explicitly specify the TTL to be used. If
> no TTL is specified, then the SnapshotDescription is initially created with a
> TTL of -1 to indicate FOREVER.
> When the SnapshotDescription runs through SnapshotDescriptionUtils#validate,
> the TTL is checked to see if the default value of hbase.master.snapshot.ttl
> should be applied. The value from the config is only applied if the TTL == 0,
> but it should be -1.
> This has another nasty side-effect: any user who creates a snapshot and
> explicitly sets \{TTL => 0} will find that their snapshot gets its TTL from
> hbase.master.snapshot.TTL.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [hbase] Apache-HBase commented on pull request #3855: HBASE-26422 Support priority select reference files in StripeCompactionPolicy
Apache-HBase commented on pull request #3855: URL: https://github.com/apache/hbase/pull/3855#issuecomment-973111011 :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 _ | ||| _ HBASE-25302 Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 43s | HBASE-25302 passed | | +1 :green_heart: | compile | 1m 14s | HBASE-25302 passed | | +1 :green_heart: | shadedjars | 8m 21s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 43s | HBASE-25302 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 28s | the patch passed | | +1 :green_heart: | compile | 1m 13s | the patch passed | | +1 :green_heart: | javac | 1m 13s | the patch passed | | +1 :green_heart: | shadedjars | 8m 21s | 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 | 142m 12s | hbase-server in the patch passed. | | | | 174m 47s | | | 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-3855/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3855 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux bbf65cda8971 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | HBASE-25302 / b2571df7ae | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3855/1/testReport/ | | Max. process+thread count | 3971 (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-3855/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-26466) Immutable timeseries usecase - Create new region rather than split existing one
[
https://issues.apache.org/jira/browse/HBASE-26466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani updated HBASE-26466:
-
Description:
For insertion of immutable data usecase (specifically time-series data), region
split mechanism doesn't seem to provide better availability when ingestion rate
is very high. When we ingest lot of data, the region split policy tries to
split the given hot region based on the size (either size of all stores
combined or size of any single store exceeding max file size configured) if we
consider default {_}SteppingSplitPolicy{_}. The latest hot regions tend to
receive all latest inserts. When the region is split, the first half of the
region (say daughterA) stays on the same server whereas the second half
(daughterB) region – likely to become another hot region because all new latest
updates come to second half region in the sequential write fashion – is moved
out to other servers in the cluster. Hence, once new daughter region is
created, client traffic will be redirected to another server. Client requests
will be piled up when region split is triggered till new daughters come alive
and once done, client will have to request meta for updated daughter region and
redirect traffic to new server.
If we could have configurable region creation strategy that 1) keeps the split
disabled for the given table, and 2) create new region dynamically with
lexicographically higher start key on the same server and update it's own
region boundary, the client will have to look up meta once and continue
ingestion without any degraded SLA caused by region split transitions.
Note: region split might also encounter some complications, requiring the
procedure to be rolled back from some step, or continue with internal retries,
eventually further delaying the ingestion from clients.
There are some complications around updating live region's start and end keys
as this key range is immutable. We could brainstorm ideas around making them
optionally mutable and any issues around them. For instance, client might
continue writing data to the region with updated end key but writes will fail
for out of range keys and hence, they will lookup in meta for updated key-space
range (new region created with end key: EMPTY_END_ROW) of the table.
was:
For insertion of immutable data usecase (specifically time-series data), region
split mechanism doesn't seem to provide better availability when ingestion rate
is very high. When we ingest lot of data, the region split policy tries to
split the given hot region based on the size (either size of all stores
combined or size of any single store exceeding max file size configured) if we
consider default {_}SteppingSplitPolicy{_}. The latest hot regions tend to
receive all latest inserts. When the region is split, the first half of the
region (say daughterA) stays on the same server whereas the second half
(daughterB) region – likely to become another hot region because all new latest
updates come to second half region in the sequential write fashion – is moved
out to other servers in the cluster. Hence, once new daughter region is
created, client traffic will be redirected to another server. Client requests
will be piled up when region split is triggered till new daughters come alive
and once done, client will have to request meta for updated daughter region and
redirect traffic to new server.
If we could have configurable region creation strategy that 1) keeps the split
disabled for the given table, and 2) create new region dynamically with
lexicographically higher start key on the same server and update it's own
region boundary, the client will have to look up meta once and continue
ingestion without any degraded SLA caused by region split transitions.
Note: region split might also encounter some complications, requiring the
procedure to be rolled back from some step, or continue with internal retries,
eventually further delaying the ingestion from clients.
There are some complications around updating live region's start and end keys
as this key range is immutable. We could brainstorm ideas around making them
optionally mutable and any issues around them. For instance, client might
continue writing data to the region with updated end key but writes will fail
and hence, they will lookup in meta for updated key-space range of the table.
> Immutable timeseries usecase - Create new region rather than split existing
> one
> ---
>
> Key: HBASE-26466
> URL: https://issues.apache.org/jira/browse/HBASE-26466
> Project: HBase
> Issue Type: Brainstorming
>Reporter: Viraj Jasani
>Priority: Major
>
> For insertion of immutable data usecase (specifically time-series data),
> region split me
[GitHub] [hbase] Apache-HBase commented on pull request #3845: HBASE-26454 CreateTableProcedure still relies on temp dir and renames…
Apache-HBase commented on pull request #3845: URL: https://github.com/apache/hbase/pull/3845#issuecomment-973123279 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 8s | 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 _ | | +1 :green_heart: | mvninstall | 5m 13s | HBASE-26067 passed | | +1 :green_heart: | compile | 1m 19s | HBASE-26067 passed | | +1 :green_heart: | shadedjars | 9m 8s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 43s | HBASE-26067 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 5m 2s | 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 | 9m 12s | 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 | 212m 26s | hbase-server in the patch passed. | | | | 248m 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-3845/4/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3845 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux d449db9f1636 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 / 36b6088a26 | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3845/4/testReport/ | | Max. process+thread count | 2939 (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-3845/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] joswiatek opened a new pull request #3856: HBASE-26458 Update snapshot doc
joswiatek opened a new pull request #3856: URL: https://github.com/apache/hbase/pull/3856 https://issues.apache.org/jira/browse/HBASE-26458 and #3852 -- 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 #3856: HBASE-26458 Update snapshot doc
Apache-HBase commented on pull request #3856: URL: https://github.com/apache/hbase/pull/3856#issuecomment-973139694 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 10s | 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 _ | ||| _ branch-2 Compile Tests _ | ||| _ Patch Compile Tests _ | ||| _ Other Tests _ | | | | 2m 28s | | | 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-3856/1/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3856 | | Optional Tests | | | uname | Linux 30922ea85acb 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 | branch-2 / 8d3562c6fa | | Max. process+thread count | 41 (vs. ulimit of 12500) | | modules | C: . U: . | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3856/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-26451) Hbase Export/Import via MapReduce job
[
https://issues.apache.org/jira/browse/HBASE-26451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17446094#comment-17446094
]
Peter Somogyi commented on HBASE-26451:
---
Hi [~xdosis],
Import will add all the HFiles to HBase with the timestamps it was originally
inserted with. HBase will _"merge"_ all the HFiles when you run a request and
gets you the _latest_ data. Since you had the same HFiles twice the only
difference was the delete thumbstone for a single rowkey for which the
timestamp was the latest so HBase did not give you back that row.
It could look something like this:
1. Original state in table:
||rowkey||column family||timestamp||value||
|r1|f1|1|a|
|r2|f1|2|b|
|r3|f1|3|c|
2. Run export
3. Delete r2
||rowkey||column family||timestamp||value||
|r1|f1|1|a|
|r2|f1|2|b|
|r3|f1|3|c|
|r2|f1|4||
4. Run import
||rowkey||column family||timestamp||value||
|r1|f1|1|a|
|r2|f1|2|b|
|r3|f1|3|c|
|r2|f1|4||
|r1|f1|1|a|
|r2|f1|2|b|
|r3|f1|3|c|
>From this if you run a scan in the table HBase will give you back only the
>following:
||rowkey||column family||timestamp||value||
|r1|f1|1|a|
|r3|f1|3|c|
> Hbase Export/Import via MapReduce job
> -
>
> Key: HBASE-26451
> URL: https://issues.apache.org/jira/browse/HBASE-26451
> Project: HBase
> Issue Type: Bug
> Components: backup&restore
>Affects Versions: 2.0.1
>Reporter: Christos Dosis
>Priority: Major
>
> Hi Hbase support team,
>
> While using the MapReduce job with export/import commands we have the below
> behaviour.
>
> {+}Step1{+}: I have a hbase table(tsdb) with 3 rows. and export the table
> like below:
> /opt/hbase/bin/hbase org.apache.hadoop.hbase.mapreduce.Export tsdb
> file:///opt/hbase/backup/tsdb
> {+}Step2{+}: Then I delete 1 row.
> {+}Step3{+}: Then I import tsdb table from the exported data from Step 1.
> /opt/hbase/bin/hbase org.apache.hadoop.hbase.mapreduce.Import tsdb
> file:///opt/hbase/backup/tsdb
>
> There are still only 2 rows in the table. Is this a valid behaviour?
>
> Br,
> Chris
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [hbase] joswiatek opened a new pull request #3857: HBASE-22458 Add UNSET_SNAPSHOT_PROP and fix TTL defaulting
joswiatek opened a new pull request #3857: URL: https://github.com/apache/hbase/pull/3857 https://issues.apache.org/jira/browse/HBASE-26458 Note that this change is possible in branch-1 because the TTL determined from the snapshotProps is always included in the protobuf in this code: https://github.com/apache/hbase/blob/0d214ff53e3b8cb3bccbc01815ccbc9a03dfabb4/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java#L3708-L3717 This is notably different from master and branch-2, where the TTL is only set if it is valid. If it is not set, then the default protobuf value of 0 is used, which matches `NO_SNAPSHOT_TTL_SPECIFIED`: https://github.com/apache/hbase/blob/b2571df7ae04307c0dbe28caed59aa383d7eec45/hbase-client/src/main/java/org/apache/hadoop/hbase/shaded/protobuf/ProtobufUtil.java#L3089-L3092 -- 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 #3856: HBASE-26458 Update snapshot doc
Apache-HBase commented on pull request #3856: URL: https://github.com/apache/hbase/pull/3856#issuecomment-973143935 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 7m 6s | 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 _ | ||| _ branch-2 Compile Tests _ | ||| _ Patch Compile Tests _ | ||| _ Other Tests _ | | | | 8m 28s | | | 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-3856/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3856 | | Optional Tests | | | uname | Linux 2b42de00fad8 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 | branch-2 / 8d3562c6fa | | Max. process+thread count | 56 (vs. ulimit of 12500) | | modules | C: . U: . | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3856/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] [Created] (HBASE-26467) Wrong Cell Generated by MemStoreLABImpl.forceCopyOfBigCellInto when Cell size bigger than data chunk size
zhuobin zheng created HBASE-26467:
-
Summary: Wrong Cell Generated by
MemStoreLABImpl.forceCopyOfBigCellInto when Cell size bigger than data chunk
size
Key: HBASE-26467
URL: https://issues.apache.org/jira/browse/HBASE-26467
Project: HBase
Issue Type: Bug
Reporter: zhuobin zheng
In our company 2.X cluster. I found some region compaction keeps failling
because some cell can't construct succefully. In fact , we even can't read
these cell.
>From follow stack , we can found the bug cause KeyValue can't constructed.
Simple Log and Stack:
{code:java}
// code placeholder
2021-11-18 16:50:47,708 ERROR [regionserver/:60020-longCompactions-4]
regionserver.CompactSplit: Compaction failed
region=xx_table,3610ff49595a0fc4a824f2a575f37a31,1570874723992.dac703ceb35e8d8703233bebf34ae49f.,
storeName=c, priority=-319, startTime=1637225447127
java.lang.IllegalArgumentException: Invalid tag length at position=4659867,
tagLength=0,
at
org.apache.hadoop.hbase.KeyValueUtil.checkKeyValueTagBytes(KeyValueUtil.java:685)
at
org.apache.hadoop.hbase.KeyValueUtil.checkKeyValueBytes(KeyValueUtil.java:643)
at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:345)
at
org.apache.hadoop.hbase.SizeCachedKeyValue.(SizeCachedKeyValue.java:43)
at
org.apache.hadoop.hbase.io.hfile.HFileReaderImpl$HFileScannerImpl.getCell(HFileReaderImpl.java:981)
at
org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:233)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.seekScanners(StoreScanner.java:418)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:322)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:288)
at
org.apache.hadoop.hbase.regionserver.compactions.Compactor.createScanner(Compactor.java:487)
at
org.apache.hadoop.hbase.regionserver.compactions.Compactor$1.createScanner(Compactor.java:248)
at
org.apache.hadoop.hbase.regionserver.compactions.Compactor.compact(Compactor.java:318)
at
org.apache.hadoop.hbase.regionserver.compactions.DefaultCompactor.compact(DefaultCompactor.java:65)
at
org.apache.hadoop.hbase.regionserver.DefaultStoreEngine$DefaultCompactionContext.compact(DefaultStoreEngine.java:126)
at org.apache.hadoop.hbase.regionserver.HStore.compact(HStore.java:1468)
at
org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:2266)
at
org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.doCompaction(CompactSplit.java:624)
at
org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.run(CompactSplit.java:666)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748) {code}
>From further observation, I found the following characteristics:
# Cell size more than 2M
# We can reproduce the bug only after in memory compact
# Cell bytes end with \x00\x02\x00\x00
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (HBASE-26467) Wrong Cell Generated by MemStoreLABImpl.forceCopyOfBigCellInto when Cell size bigger than data chunk size
[
https://issues.apache.org/jira/browse/HBASE-26467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhuobin zheng reassigned HBASE-26467:
-
Assignee: zhuobin zheng
> Wrong Cell Generated by MemStoreLABImpl.forceCopyOfBigCellInto when Cell size
> bigger than data chunk size
> --
>
> Key: HBASE-26467
> URL: https://issues.apache.org/jira/browse/HBASE-26467
> Project: HBase
> Issue Type: Bug
>Reporter: zhuobin zheng
>Assignee: zhuobin zheng
>Priority: Critical
>
> In our company 2.X cluster. I found some region compaction keeps failling
> because some cell can't construct succefully. In fact , we even can't read
> these cell.
> From follow stack , we can found the bug cause KeyValue can't constructed.
> Simple Log and Stack:
> {code:java}
> // code placeholder
> 2021-11-18 16:50:47,708 ERROR [regionserver/:60020-longCompactions-4]
> regionserver.CompactSplit: Compaction failed
> region=xx_table,3610ff49595a0fc4a824f2a575f37a31,1570874723992.dac703ceb35e8d8703233bebf34ae49f.,
> storeName=c, priority=-319, startTime=1637225447127
> java.lang.IllegalArgumentException: Invalid tag length at position=4659867,
> tagLength=0,
> at
> org.apache.hadoop.hbase.KeyValueUtil.checkKeyValueTagBytes(KeyValueUtil.java:685)
> at
> org.apache.hadoop.hbase.KeyValueUtil.checkKeyValueBytes(KeyValueUtil.java:643)
> at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:345)
> at
> org.apache.hadoop.hbase.SizeCachedKeyValue.(SizeCachedKeyValue.java:43)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderImpl$HFileScannerImpl.getCell(HFileReaderImpl.java:981)
> at
> org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:233)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.seekScanners(StoreScanner.java:418)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:322)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:288)
> at
> org.apache.hadoop.hbase.regionserver.compactions.Compactor.createScanner(Compactor.java:487)
> at
> org.apache.hadoop.hbase.regionserver.compactions.Compactor$1.createScanner(Compactor.java:248)
> at
> org.apache.hadoop.hbase.regionserver.compactions.Compactor.compact(Compactor.java:318)
> at
> org.apache.hadoop.hbase.regionserver.compactions.DefaultCompactor.compact(DefaultCompactor.java:65)
> at
> org.apache.hadoop.hbase.regionserver.DefaultStoreEngine$DefaultCompactionContext.compact(DefaultStoreEngine.java:126)
> at
> org.apache.hadoop.hbase.regionserver.HStore.compact(HStore.java:1468)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:2266)
> at
> org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.doCompaction(CompactSplit.java:624)
> at
> org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.run(CompactSplit.java:666)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748) {code}
> From further observation, I found the following characteristics:
> # Cell size more than 2M
> # We can reproduce the bug only after in memory compact
> # Cell bytes end with \x00\x02\x00\x00
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [hbase] Apache-HBase commented on pull request #3856: HBASE-26458 Update snapshot doc
Apache-HBase commented on pull request #3856: URL: https://github.com/apache/hbase/pull/3856#issuecomment-973151430 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 10s | Docker mode activated. | ||| _ Prechecks _ | | +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. | | +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. | ||| _ branch-2 Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 13s | branch-2 passed | | -1 :x: | refguide | 3m 56s | branch has 2 errors when building the reference guide. | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 3m 56s | the patch passed | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | -1 :x: | refguide | 3m 38s | patch has 2 errors when building the reference guide. | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 16s | The patch does not generate ASF License warnings. | | | | 18m 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-3856/1/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3856 | | Optional Tests | dupname asflicense refguide | | uname | Linux 1df6bda3ce85 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 | branch-2 / 8d3562c6fa | | refguide | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3856/1/artifact/yetus-general-check/output/branch-refguide.log | | refguide | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3856/1/artifact/yetus-general-check/output/patch-refguide.log | | Max. process+thread count | 66 (vs. ulimit of 12500) | | modules | C: . U: . | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3856/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 #3845: HBASE-26454 CreateTableProcedure still relies on temp dir and renames…
Apache-HBase commented on pull request #3845: URL: https://github.com/apache/hbase/pull/3845#issuecomment-973152603 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 57s | 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-26067 Compile Tests _ | | +1 :green_heart: | mvninstall | 5m 25s | HBASE-26067 passed | | +1 :green_heart: | compile | 1m 16s | HBASE-26067 passed | | +1 :green_heart: | shadedjars | 9m 55s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 44s | HBASE-26067 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 46s | 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 | 9m 58s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 46s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 247m 29s | hbase-server in the patch passed. | | | | 285m 49s | | | 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-3845/4/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3845 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 441d9e70c035 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 / 36b6088a26 | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3845/4/testReport/ | | Max. process+thread count | 3779 (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-3845/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] [Updated] (HBASE-26467) Wrong Cell Generated by MemStoreLABImpl.forceCopyOfBigCellInto when Cell size bigger than data chunk size
[
https://issues.apache.org/jira/browse/HBASE-26467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhuobin zheng updated HBASE-26467:
--
Description:
In our company 2.X cluster. I found some region compaction keeps failling
because some cell can't construct succefully. In fact , we even can't read
these cell.
>From follow stack , we can found the bug cause KeyValue can't constructed.
Simple Log and Stack:
{code:java}
// code placeholder
2021-11-18 16:50:47,708 ERROR [regionserver/:60020-longCompactions-4]
regionserver.CompactSplit: Compaction failed
region=xx_table,3610ff49595a0fc4a824f2a575f37a31,1570874723992.dac703ceb35e8d8703233bebf34ae49f.,
storeName=c, priority=-319, startTime=1637225447127
java.lang.IllegalArgumentException: Invalid tag length at position=4659867,
tagLength=0,
at
org.apache.hadoop.hbase.KeyValueUtil.checkKeyValueTagBytes(KeyValueUtil.java:685)
at
org.apache.hadoop.hbase.KeyValueUtil.checkKeyValueBytes(KeyValueUtil.java:643)
at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:345)
at
org.apache.hadoop.hbase.SizeCachedKeyValue.(SizeCachedKeyValue.java:43)
at
org.apache.hadoop.hbase.io.hfile.HFileReaderImpl$HFileScannerImpl.getCell(HFileReaderImpl.java:981)
at
org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:233)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.seekScanners(StoreScanner.java:418)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:322)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:288)
at
org.apache.hadoop.hbase.regionserver.compactions.Compactor.createScanner(Compactor.java:487)
at
org.apache.hadoop.hbase.regionserver.compactions.Compactor$1.createScanner(Compactor.java:248)
at
org.apache.hadoop.hbase.regionserver.compactions.Compactor.compact(Compactor.java:318)
at
org.apache.hadoop.hbase.regionserver.compactions.DefaultCompactor.compact(DefaultCompactor.java:65)
at
org.apache.hadoop.hbase.regionserver.DefaultStoreEngine$DefaultCompactionContext.compact(DefaultStoreEngine.java:126)
at org.apache.hadoop.hbase.regionserver.HStore.compact(HStore.java:1468)
at
org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:2266)
at
org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.doCompaction(CompactSplit.java:624)
at
org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.run(CompactSplit.java:666)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748) {code}
>From further observation, I found the following characteristics:
# Cell size more than 2M
# We can reproduce the bug only after in memory compact
# Cell bytes end with \x00\x02\x00\x00
In fact, the root reason is method (MemStoreLABImpl.forceCopyOfBigCellInto)
which only invoked when cell bigger than data chunk size construct cell with
wrong length. So there are 4 bytes (chunk head size) append end of the cell
bytes.
was:
In our company 2.X cluster. I found some region compaction keeps failling
because some cell can't construct succefully. In fact , we even can't read
these cell.
>From follow stack , we can found the bug cause KeyValue can't constructed.
Simple Log and Stack:
{code:java}
// code placeholder
2021-11-18 16:50:47,708 ERROR [regionserver/:60020-longCompactions-4]
regionserver.CompactSplit: Compaction failed
region=xx_table,3610ff49595a0fc4a824f2a575f37a31,1570874723992.dac703ceb35e8d8703233bebf34ae49f.,
storeName=c, priority=-319, startTime=1637225447127
java.lang.IllegalArgumentException: Invalid tag length at position=4659867,
tagLength=0,
at
org.apache.hadoop.hbase.KeyValueUtil.checkKeyValueTagBytes(KeyValueUtil.java:685)
at
org.apache.hadoop.hbase.KeyValueUtil.checkKeyValueBytes(KeyValueUtil.java:643)
at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:345)
at
org.apache.hadoop.hbase.SizeCachedKeyValue.(SizeCachedKeyValue.java:43)
at
org.apache.hadoop.hbase.io.hfile.HFileReaderImpl$HFileScannerImpl.getCell(HFileReaderImpl.java:981)
at
org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:233)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.seekScanners(StoreScanner.java:418)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:322)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:288)
at
org.apache.hadoop.hbase.regionserver.compactions.Compactor.createScanner(Compactor.java:487)
at
org.apache.hadoop.hbase.regionserver.compactions.Compactor$1.createScanner(Compactor.java:248)
[jira] [Work started] (HBASE-26467) Wrong Cell Generated by MemStoreLABImpl.forceCopyOfBigCellInto when Cell size bigger than data chunk size
[
https://issues.apache.org/jira/browse/HBASE-26467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HBASE-26467 started by zhuobin zheng.
-
> Wrong Cell Generated by MemStoreLABImpl.forceCopyOfBigCellInto when Cell size
> bigger than data chunk size
> --
>
> Key: HBASE-26467
> URL: https://issues.apache.org/jira/browse/HBASE-26467
> Project: HBase
> Issue Type: Bug
>Reporter: zhuobin zheng
>Assignee: zhuobin zheng
>Priority: Critical
>
> In our company 2.X cluster. I found some region compaction keeps failling
> because some cell can't construct succefully. In fact , we even can't read
> these cell.
> From follow stack , we can found the bug cause KeyValue can't constructed.
> Simple Log and Stack:
> {code:java}
> // code placeholder
> 2021-11-18 16:50:47,708 ERROR [regionserver/:60020-longCompactions-4]
> regionserver.CompactSplit: Compaction failed
> region=xx_table,3610ff49595a0fc4a824f2a575f37a31,1570874723992.dac703ceb35e8d8703233bebf34ae49f.,
> storeName=c, priority=-319, startTime=1637225447127
> java.lang.IllegalArgumentException: Invalid tag length at position=4659867,
> tagLength=0,
> at
> org.apache.hadoop.hbase.KeyValueUtil.checkKeyValueTagBytes(KeyValueUtil.java:685)
> at
> org.apache.hadoop.hbase.KeyValueUtil.checkKeyValueBytes(KeyValueUtil.java:643)
> at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:345)
> at
> org.apache.hadoop.hbase.SizeCachedKeyValue.(SizeCachedKeyValue.java:43)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderImpl$HFileScannerImpl.getCell(HFileReaderImpl.java:981)
> at
> org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:233)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.seekScanners(StoreScanner.java:418)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:322)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:288)
> at
> org.apache.hadoop.hbase.regionserver.compactions.Compactor.createScanner(Compactor.java:487)
> at
> org.apache.hadoop.hbase.regionserver.compactions.Compactor$1.createScanner(Compactor.java:248)
> at
> org.apache.hadoop.hbase.regionserver.compactions.Compactor.compact(Compactor.java:318)
> at
> org.apache.hadoop.hbase.regionserver.compactions.DefaultCompactor.compact(DefaultCompactor.java:65)
> at
> org.apache.hadoop.hbase.regionserver.DefaultStoreEngine$DefaultCompactionContext.compact(DefaultStoreEngine.java:126)
> at
> org.apache.hadoop.hbase.regionserver.HStore.compact(HStore.java:1468)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:2266)
> at
> org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.doCompaction(CompactSplit.java:624)
> at
> org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.run(CompactSplit.java:666)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748) {code}
> From further observation, I found the following characteristics:
> # Cell size more than 2M
> # We can reproduce the bug only after in memory compact
> # Cell bytes end with \x00\x02\x00\x00
>
> In fact, the root reason is method (MemStoreLABImpl.forceCopyOfBigCellInto)
> which only invoked when cell bigger than data chunk size construct cell with
> wrong length. So there are 4 bytes (chunk head size) append end of the cell
> bytes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [hbase] Apache-HBase commented on pull request #3855: HBASE-26422 Support priority select reference files in StripeCompactionPolicy
Apache-HBase commented on pull request #3855: URL: https://github.com/apache/hbase/pull/3855#issuecomment-973175911 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 6m 49s | 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-25302 Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 37s | HBASE-25302 passed | | +1 :green_heart: | compile | 1m 6s | HBASE-25302 passed | | +1 :green_heart: | shadedjars | 9m 10s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 41s | HBASE-25302 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 20s | 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 11s | patch has no errors when building our shaded downstream artifacts. | | -0 :warning: | javadoc | 0m 39s | hbase-server generated 1 new + 21 unchanged - 0 fixed = 22 total (was 21) | ||| _ Other Tests _ | | -1 :x: | unit | 220m 58s | hbase-server in the patch failed. | | | | 260m 33s | | | 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-3855/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3855 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 202c5626ac57 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-25302 / b2571df7ae | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | javadoc | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3855/1/artifact/yetus-jdk8-hadoop3-check/output/diff-javadoc-javadoc-hbase-server.txt | | unit | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3855/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-3855/1/testReport/ | | Max. process+thread count | 3342 (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-3855/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-26467) Wrong Cell Generated by MemStoreLABImpl.forceCopyOfBigCellInto when Cell size bigger than data chunk size
[
https://issues.apache.org/jira/browse/HBASE-26467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhuobin zheng updated HBASE-26467:
--
Status: Patch Available (was: In Progress)
https://github.com/apache/hbase/pull/3858
> Wrong Cell Generated by MemStoreLABImpl.forceCopyOfBigCellInto when Cell size
> bigger than data chunk size
> --
>
> Key: HBASE-26467
> URL: https://issues.apache.org/jira/browse/HBASE-26467
> Project: HBase
> Issue Type: Bug
>Reporter: zhuobin zheng
>Assignee: zhuobin zheng
>Priority: Critical
>
> In our company 2.X cluster. I found some region compaction keeps failling
> because some cell can't construct succefully. In fact , we even can't read
> these cell.
> From follow stack , we can found the bug cause KeyValue can't constructed.
> Simple Log and Stack:
> {code:java}
> // code placeholder
> 2021-11-18 16:50:47,708 ERROR [regionserver/:60020-longCompactions-4]
> regionserver.CompactSplit: Compaction failed
> region=xx_table,3610ff49595a0fc4a824f2a575f37a31,1570874723992.dac703ceb35e8d8703233bebf34ae49f.,
> storeName=c, priority=-319, startTime=1637225447127
> java.lang.IllegalArgumentException: Invalid tag length at position=4659867,
> tagLength=0,
> at
> org.apache.hadoop.hbase.KeyValueUtil.checkKeyValueTagBytes(KeyValueUtil.java:685)
> at
> org.apache.hadoop.hbase.KeyValueUtil.checkKeyValueBytes(KeyValueUtil.java:643)
> at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:345)
> at
> org.apache.hadoop.hbase.SizeCachedKeyValue.(SizeCachedKeyValue.java:43)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderImpl$HFileScannerImpl.getCell(HFileReaderImpl.java:981)
> at
> org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:233)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.seekScanners(StoreScanner.java:418)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:322)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:288)
> at
> org.apache.hadoop.hbase.regionserver.compactions.Compactor.createScanner(Compactor.java:487)
> at
> org.apache.hadoop.hbase.regionserver.compactions.Compactor$1.createScanner(Compactor.java:248)
> at
> org.apache.hadoop.hbase.regionserver.compactions.Compactor.compact(Compactor.java:318)
> at
> org.apache.hadoop.hbase.regionserver.compactions.DefaultCompactor.compact(DefaultCompactor.java:65)
> at
> org.apache.hadoop.hbase.regionserver.DefaultStoreEngine$DefaultCompactionContext.compact(DefaultStoreEngine.java:126)
> at
> org.apache.hadoop.hbase.regionserver.HStore.compact(HStore.java:1468)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:2266)
> at
> org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.doCompaction(CompactSplit.java:624)
> at
> org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.run(CompactSplit.java:666)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748) {code}
> From further observation, I found the following characteristics:
> # Cell size more than 2M
> # We can reproduce the bug only after in memory compact
> # Cell bytes end with \x00\x02\x00\x00
>
> In fact, the root reason is method (MemStoreLABImpl.forceCopyOfBigCellInto)
> which only invoked when cell bigger than data chunk size construct cell with
> wrong length. So there are 4 bytes (chunk head size) append end of the cell
> bytes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [hbase] Apache-HBase commented on pull request #3858: HBASE-26467 Fix bug for MemStoreLABImpl.forceCopyOfBigCellInto(Cell)
Apache-HBase commented on pull request #3858: URL: https://github.com/apache/hbase/pull/3858#issuecomment-973201775 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 28s | 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 9s | master passed | | +1 :green_heart: | compile | 3m 12s | master passed | | +1 :green_heart: | checkstyle | 1m 4s | master passed | | +1 :green_heart: | spotbugs | 2m 4s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 3m 50s | the patch passed | | +1 :green_heart: | compile | 3m 12s | the patch passed | | +1 :green_heart: | javac | 3m 12s | the patch passed | | -0 :warning: | checkstyle | 1m 4s | hbase-server: The patch generated 1 new + 18 unchanged - 0 fixed = 19 total (was 18) | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +1 :green_heart: | hadoopcheck | 19m 32s | Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1. | | +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. | | | | 49m 20s | | | 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-3858/1/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3858 | | Optional Tests | dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux 43a2955ac976 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / b2571df7ae | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | checkstyle | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3858/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt | | Max. process+thread count | 96 (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-3858/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 #3852: HBASE-26458 Update Snapshot TTL doc
Apache-HBase commented on pull request #3852: URL: https://github.com/apache/hbase/pull/3852#issuecomment-973211636 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 58s | 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 _ | | +0 :ok: | mvndep | 0m 29s | Maven dependency ordering for branch | | +1 :green_heart: | mvninstall | 4m 29s | master passed | | +1 :green_heart: | compile | 9m 54s | master passed | | +1 :green_heart: | checkstyle | 2m 12s | master passed | | +0 :ok: | refguide | 3m 47s | branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect. | | +1 :green_heart: | spotbugs | 15m 28s | master passed | ||| _ Patch Compile Tests _ | | +0 :ok: | mvndep | 0m 16s | Maven dependency ordering for patch | | +1 :green_heart: | mvninstall | 4m 35s | the patch passed | | +1 :green_heart: | compile | 10m 21s | the patch passed | | +1 :green_heart: | javac | 10m 21s | the patch passed | | +1 :green_heart: | checkstyle | 2m 12s | the patch passed | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +0 :ok: | refguide | 4m 5s | patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect. | | +1 :green_heart: | hadoopcheck | 20m 49s | Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1. | | +1 :green_heart: | spotbugs | 14m 41s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 56s | The patch does not generate ASF License warnings. | | | | 104m 40s | | | 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-3852/2/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3852 | | Optional Tests | dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile refguide | | uname | Linux 9d17c07c44f8 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / b2571df7ae | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | refguide | https://nightlies.apache.org/hbase/HBase/HBase-PreCommit-GitHub-PR/PR-3852/2/yetus-general-check/output/branch-site/book.html | | refguide | https://nightlies.apache.org/hbase/HBase/HBase-PreCommit-GitHub-PR/PR-3852/2/yetus-general-check/output/patch-site/book.html | | Max. process+thread count | 141 (vs. ulimit of 3) | | modules | C: hbase-common hbase-client hbase-server . U: . | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/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 #3855: HBASE-26422 Support priority select reference files in StripeCompactionPolicy
Apache-HBase commented on pull request #3855: URL: https://github.com/apache/hbase/pull/3855#issuecomment-973226076 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 37s | 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-25302 Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 45s | HBASE-25302 passed | | +1 :green_heart: | compile | 3m 34s | HBASE-25302 passed | | +1 :green_heart: | checkstyle | 1m 11s | HBASE-25302 passed | | +1 :green_heart: | spotbugs | 2m 18s | HBASE-25302 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 20s | the patch passed | | +1 :green_heart: | compile | 3m 35s | the patch passed | | +1 :green_heart: | javac | 3m 35s | the patch passed | | -0 :warning: | checkstyle | 1m 12s | hbase-server: The patch generated 1 new + 23 unchanged - 1 fixed = 24 total (was 24) | | -0 :warning: | whitespace | 0m 0s | The patch has 3 line(s) that end in whitespace. Use git apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply | | +1 :green_heart: | hadoopcheck | 23m 30s | Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1. | | +1 :green_heart: | spotbugs | 2m 57s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 15s | The patch does not generate ASF License warnings. | | | | 59m 40s | | | 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-3855/2/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3855 | | Optional Tests | dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux 242f09a2f4d0 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-25302 / b2571df7ae | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | checkstyle | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3855/2/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt | | whitespace | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3855/2/artifact/yetus-general-check/output/whitespace-eol.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-3855/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] bbeaudreault commented on a change in pull request #3803: HBASE-26304: Reflect out of band locality improvements in metrics and balancer
bbeaudreault commented on a change in pull request #3803:
URL: https://github.com/apache/hbase/pull/3803#discussion_r752631908
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/InputStreamBlockDistribution.java
##
@@ -0,0 +1,143 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ * http://www.apache.org/licenses/LICENSE-2.0
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.hadoop.hbase.regionserver;
+
+import com.google.errorprone.annotations.RestrictedApi;
+import java.io.IOException;
+import org.apache.hadoop.conf.Configuration;
+import org.apache.hadoop.fs.FSDataInputStream;
+import org.apache.hadoop.hbase.HDFSBlocksDistribution;
+import org.apache.hadoop.hbase.io.FileLink;
+import org.apache.hadoop.hbase.util.EnvironmentEdgeManager;
+import org.apache.hadoop.hbase.util.FSUtils;
+import org.apache.hadoop.hdfs.client.HdfsDataInputStream;
+import org.apache.yetus.audience.InterfaceAudience;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+/**
+ * Computes the HDFSBlockDistribution for a file based on the underlying
located blocks
+ * for an HdfsDataInputStream reading that file. This computation may involve
a call to
+ * the namenode, so the value is cached based on
+ * {@link #HBASE_LOCALITY_INPUTSTREAM_DERIVE_CACHE_PERIOD}.
+ */
+@InterfaceAudience.Private
+public class InputStreamBlockDistribution {
+ private static final Logger LOG =
LoggerFactory.getLogger(InputStreamBlockDistribution.class);
+
+ private static final String HBASE_LOCALITY_INPUTSTREAM_DERIVE_ENABLED =
+"hbase.locality.inputstream.derive.enabled";
+ private static final boolean
DEFAULT_HBASE_LOCALITY_INPUTSTREAM_DERIVE_ENABLED = false;
+
+ private static final String HBASE_LOCALITY_INPUTSTREAM_DERIVE_CACHE_PERIOD =
+"hbase.locality.inputstream.derive.cache.period";
+ private static final int
DEFAULT_HBASE_LOCALITY_INPUTSTREAM_DERIVE_CACHE_PERIOD = 60_000;
+
+ private final FSDataInputStream stream;
+ private final StoreFileInfo fileInfo;
+ private final int cachePeriodMs;
+
+ private HDFSBlocksDistribution hdfsBlocksDistribution;
+ private long lastCachedAt;
+ private boolean streamUnsupported;
+
+ public InputStreamBlockDistribution(FSDataInputStream stream, StoreFileInfo
fileInfo) {
+this.stream = stream;
Review comment:
Thanks for reviewing, Duo!
The stream is originally constructed here in
[StoreFileInfo.createReaderContext](
https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileInfo.java#L293-L329).
This method has two usages:
-
[HStoreFile.open](https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStoreFile.java#L357),
when opening a StoreFile and creating the `initialReader` which is used for
all PREAD scans.
-
[HStoreFile.createStreamScanner](https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStoreFile.java#L499),
which is used for STREAM scans
I'm interested in the first one, because it lives for the lifetime of a
StoreFile. As far as I can tell, the initialReader (and thus this input stream)
is never closed until the StoreFile itself closes. To your question, I don't
think it makes sense to continue computing locality at that point. I don't see
a case for the InputStream to be re-opened except through re-opening the
StoreFile which would actually create a new FSDataInputStream and subsequently
a new InputStreamBlockDistribution.
The second one is relatively short lived, just for the lifetime of the scan.
And nothing would be trying to fetch the locality from such a scan. So it
doesn't make sense to worry too much about that one.
---
Part of your question seems to be probing at whether this is too far removed
from where the object is created. I could have considered putting all of the
logic from this class into HStoreFile so it's clear that it's directly tied to
that object's initialReader. However, HStoreFile is already a long class and
IMO it's cleaner to put this nicely encapsulated logic in a separate class.
This also makes it easier to test.
I could also consider embedding this constructor call clo
[GitHub] [hbase] Apache-HBase commented on pull request #3858: HBASE-26467 Fix bug for MemStoreLABImpl.forceCopyOfBigCellInto(Cell)
Apache-HBase commented on pull request #3858: URL: https://github.com/apache/hbase/pull/3858#issuecomment-973301818 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 4m 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 _ | ||| _ master Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 46s | master passed | | +1 :green_heart: | compile | 1m 14s | master passed | | +1 :green_heart: | shadedjars | 8m 17s | 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 28s | 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 16s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 42s | the patch passed | ||| _ Other Tests _ | | -1 :x: | unit | 140m 29s | hbase-server in the patch failed. | | | | 176m 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-3858/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3858 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux f9cd4294eb00 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 / b2571df7ae | | Default Java | AdoptOpenJDK-11.0.10+9 | | unit | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3858/1/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-3858/1/testReport/ | | Max. process+thread count | 3996 (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-3858/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] [Created] (HBASE-26468) Region Server doesn't exit cleanly incase it crashes.
Rushabh Shah created HBASE-26468:
Summary: Region Server doesn't exit cleanly incase it crashes.
Key: HBASE-26468
URL: https://issues.apache.org/jira/browse/HBASE-26468
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 1.6.0
Reporter: Rushabh Shah
Observed this in our production cluster running 1.6 version.
RS crashed due to some reason but the process was still running. On debugging
more, found out there was 1 non-daemon thread running and that was not allowing
RS to stop cleanly. Our clusters are managed by Ambari and have auto restart
capability within them. But since the process was running and pid file was
present, Ambari also couldn't do much. There will be some bug where we will
miss to stop some daemon thread but there should be some maximum amount of time
we should wait before exiting the thread.
Relevant code:
[HRegionServerCommandLine.java|https://github.com/apache/hbase/blob/branch-2/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServerCommandLine.java]
{code:java}
logProcessInfo(getConf());
HRegionServer hrs =
HRegionServer.constructRegionServer(regionServerClass, conf);
hrs.start();
hrs.join(); -> This should be a timed join.
if (hrs.isAborted()) {
throw new RuntimeException("HRegionServer Aborted");
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (HBASE-26468) Region Server doesn't exit cleanly incase it crashes.
[
https://issues.apache.org/jira/browse/HBASE-26468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rushabh Shah updated HBASE-26468:
-
Description:
Observed this in our production cluster running 1.6 version.
RS crashed due to some reason but the process was still running. On debugging
more, found out there was 1 non-daemon thread running and that was not allowing
RS to exit cleanly. Our clusters are managed by Ambari and have auto restart
capability within them. But since the process was running and pid file was
present, Ambari also couldn't do much. There will be some bug where we will
miss to stop some daemon thread but there should be some maximum amount of time
we should wait before exiting the thread.
Relevant code:
[HRegionServerCommandLine.java|https://github.com/apache/hbase/blob/branch-2/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServerCommandLine.java]
{code:java}
logProcessInfo(getConf());
HRegionServer hrs =
HRegionServer.constructRegionServer(regionServerClass, conf);
hrs.start();
hrs.join(); -> This should be a timed join.
if (hrs.isAborted()) {
throw new RuntimeException("HRegionServer Aborted");
}
}
{code}
was:
Observed this in our production cluster running 1.6 version.
RS crashed due to some reason but the process was still running. On debugging
more, found out there was 1 non-daemon thread running and that was not allowing
RS to stop cleanly. Our clusters are managed by Ambari and have auto restart
capability within them. But since the process was running and pid file was
present, Ambari also couldn't do much. There will be some bug where we will
miss to stop some daemon thread but there should be some maximum amount of time
we should wait before exiting the thread.
Relevant code:
[HRegionServerCommandLine.java|https://github.com/apache/hbase/blob/branch-2/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServerCommandLine.java]
{code:java}
logProcessInfo(getConf());
HRegionServer hrs =
HRegionServer.constructRegionServer(regionServerClass, conf);
hrs.start();
hrs.join(); -> This should be a timed join.
if (hrs.isAborted()) {
throw new RuntimeException("HRegionServer Aborted");
}
}
{code}
> Region Server doesn't exit cleanly incase it crashes.
> -
>
> Key: HBASE-26468
> URL: https://issues.apache.org/jira/browse/HBASE-26468
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 1.6.0
>Reporter: Rushabh Shah
>Priority: Major
>
> Observed this in our production cluster running 1.6 version.
> RS crashed due to some reason but the process was still running. On debugging
> more, found out there was 1 non-daemon thread running and that was not
> allowing RS to exit cleanly. Our clusters are managed by Ambari and have auto
> restart capability within them. But since the process was running and pid
> file was present, Ambari also couldn't do much. There will be some bug where
> we will miss to stop some daemon thread but there should be some maximum
> amount of time we should wait before exiting the thread.
> Relevant code:
> [HRegionServerCommandLine.java|https://github.com/apache/hbase/blob/branch-2/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServerCommandLine.java]
> {code:java}
> logProcessInfo(getConf());
> HRegionServer hrs =
> HRegionServer.constructRegionServer(regionServerClass, conf);
> hrs.start();
> hrs.join(); -> This should be a timed join.
> if (hrs.isAborted()) {
> throw new RuntimeException("HRegionServer Aborted");
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (HBASE-26468) Region Server doesn't exit cleanly incase it crashes.
[
https://issues.apache.org/jira/browse/HBASE-26468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rushabh Shah updated HBASE-26468:
-
Description:
Observed this in our production cluster running 1.6 version.
RS crashed due to some reason but the process was still running. On debugging
more, found out there was 1 non-daemon thread running and that was not allowing
RS to exit cleanly. Our clusters are managed by Ambari and have auto restart
capability within them. But since the process was running and pid file was
present, Ambari also couldn't do much. There will be some bug where we will
miss to stop some non daemon thread but there should be some maximum amount of
time we should wait before exiting the thread.
Relevant code:
[HRegionServerCommandLine.java|https://github.com/apache/hbase/blob/branch-2/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServerCommandLine.java]
{code:java}
logProcessInfo(getConf());
HRegionServer hrs =
HRegionServer.constructRegionServer(regionServerClass, conf);
hrs.start();
hrs.join(); -> This should be a timed join.
if (hrs.isAborted()) {
throw new RuntimeException("HRegionServer Aborted");
}
}
{code}
was:
Observed this in our production cluster running 1.6 version.
RS crashed due to some reason but the process was still running. On debugging
more, found out there was 1 non-daemon thread running and that was not allowing
RS to exit cleanly. Our clusters are managed by Ambari and have auto restart
capability within them. But since the process was running and pid file was
present, Ambari also couldn't do much. There will be some bug where we will
miss to stop some daemon thread but there should be some maximum amount of time
we should wait before exiting the thread.
Relevant code:
[HRegionServerCommandLine.java|https://github.com/apache/hbase/blob/branch-2/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServerCommandLine.java]
{code:java}
logProcessInfo(getConf());
HRegionServer hrs =
HRegionServer.constructRegionServer(regionServerClass, conf);
hrs.start();
hrs.join(); -> This should be a timed join.
if (hrs.isAborted()) {
throw new RuntimeException("HRegionServer Aborted");
}
}
{code}
> Region Server doesn't exit cleanly incase it crashes.
> -
>
> Key: HBASE-26468
> URL: https://issues.apache.org/jira/browse/HBASE-26468
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 1.6.0
>Reporter: Rushabh Shah
>Priority: Major
>
> Observed this in our production cluster running 1.6 version.
> RS crashed due to some reason but the process was still running. On debugging
> more, found out there was 1 non-daemon thread running and that was not
> allowing RS to exit cleanly. Our clusters are managed by Ambari and have auto
> restart capability within them. But since the process was running and pid
> file was present, Ambari also couldn't do much. There will be some bug where
> we will miss to stop some non daemon thread but there should be some maximum
> amount of time we should wait before exiting the thread.
> Relevant code:
> [HRegionServerCommandLine.java|https://github.com/apache/hbase/blob/branch-2/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServerCommandLine.java]
> {code:java}
> logProcessInfo(getConf());
> HRegionServer hrs =
> HRegionServer.constructRegionServer(regionServerClass, conf);
> hrs.start();
> hrs.join(); -> This should be a timed join.
> if (hrs.isAborted()) {
> throw new RuntimeException("HRegionServer Aborted");
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [hbase] Apache-HBase commented on pull request #3858: HBASE-26467 Fix bug for MemStoreLABImpl.forceCopyOfBigCellInto(Cell)
Apache-HBase commented on pull request #3858: URL: https://github.com/apache/hbase/pull/3858#issuecomment-973322556 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 31s | 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 14s | master passed | | +1 :green_heart: | compile | 1m 14s | master passed | | +1 :green_heart: | shadedjars | 9m 59s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 49s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 5m 21s | the patch passed | | +1 :green_heart: | compile | 1m 23s | the patch passed | | +1 :green_heart: | javac | 1m 23s | the patch passed | | +1 :green_heart: | shadedjars | 11m 32s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 46s | the patch passed | ||| _ Other Tests _ | | -1 :x: | unit | 169m 39s | hbase-server in the patch failed. | | | | 208m 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-3858/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3858 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux a50e3718afc2 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 / b2571df7ae | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | unit | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3858/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-3858/1/testReport/ | | Max. process+thread count | 3327 (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-3858/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 #3852: HBASE-26458 Update Snapshot TTL doc
Apache-HBase commented on pull request #3852: URL: https://github.com/apache/hbase/pull/3852#issuecomment-973323831 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 29s | 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 _ | | +0 :ok: | mvndep | 0m 16s | Maven dependency ordering for branch | | +1 :green_heart: | mvninstall | 4m 50s | master passed | | +1 :green_heart: | compile | 3m 13s | master passed | | +1 :green_heart: | shadedjars | 8m 22s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 4m 19s | master passed | ||| _ Patch Compile Tests _ | | +0 :ok: | mvndep | 0m 13s | Maven dependency ordering for patch | | +1 :green_heart: | mvninstall | 4m 26s | the patch passed | | +1 :green_heart: | compile | 3m 12s | the patch passed | | +1 :green_heart: | javac | 3m 12s | the patch passed | | +1 :green_heart: | shadedjars | 8m 15s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 4m 25s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 207m 40s | root in the patch passed. | | | | 253m 39s | | | 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-3852/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3852 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 4770328ba33d 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 / b2571df7ae | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/2/testReport/ | | Max. process+thread count | 7568 (vs. ulimit of 3) | | modules | C: hbase-common hbase-client hbase-server . U: . | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/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 #3855: HBASE-26422 Support priority select reference files in StripeCompactionPolicy
Apache-HBase commented on pull request #3855: URL: https://github.com/apache/hbase/pull/3855#issuecomment-973417187 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 36s | 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-25302 Compile Tests _ | | +1 :green_heart: | mvninstall | 5m 36s | HBASE-25302 passed | | +1 :green_heart: | compile | 1m 26s | HBASE-25302 passed | | +1 :green_heart: | shadedjars | 9m 27s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 51s | HBASE-25302 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 5m 15s | the patch passed | | +1 :green_heart: | compile | 1m 24s | the patch passed | | +1 :green_heart: | javac | 1m 24s | the patch passed | | +1 :green_heart: | shadedjars | 9m 10s | 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 | 211m 39s | hbase-server in the patch passed. | | | | 249m 7s | | | 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-3855/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3855 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 758973177dea 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-25302 / b2571df7ae | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3855/2/testReport/ | | Max. process+thread count | 3460 (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-3855/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 #3855: HBASE-26422 Support priority select reference files in StripeCompactionPolicy
Apache-HBase commented on pull request #3855: URL: https://github.com/apache/hbase/pull/3855#issuecomment-973422824 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 1m 2s | 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-25302 Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 27s | HBASE-25302 passed | | +1 :green_heart: | compile | 1m 3s | HBASE-25302 passed | | +1 :green_heart: | shadedjars | 9m 8s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 39s | HBASE-25302 passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 4m 15s | 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 6s | patch has no errors when building our shaded downstream artifacts. | | -0 :warning: | javadoc | 0m 38s | hbase-server generated 1 new + 21 unchanged - 0 fixed = 22 total (was 21) | ||| _ Other Tests _ | | +1 :green_heart: | unit | 216m 32s | hbase-server in the patch passed. | | | | 251m 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-3855/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3855 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 9191a9b41411 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-25302 / b2571df7ae | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | javadoc | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3855/2/artifact/yetus-jdk8-hadoop3-check/output/diff-javadoc-javadoc-hbase-server.txt | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3855/2/testReport/ | | Max. process+thread count | 3518 (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-3855/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 #3857: HBASE-26458 Add UNSET_SNAPSHOT_PROP and fix TTL defaulting
Apache-HBase commented on pull request #3857: URL: https://github.com/apache/hbase/pull/3857#issuecomment-973500407 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 5m 38s | 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. | | -0 :warning: | test4tests | 0m 0s | The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. | ||| _ branch-1 Compile Tests _ | | +0 :ok: | mvndep | 2m 34s | Maven dependency ordering for branch | | +1 :green_heart: | mvninstall | 9m 30s | branch-1 passed | | +1 :green_heart: | compile | 2m 37s | branch-1 passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | compile | 2m 54s | branch-1 passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | +1 :green_heart: | checkstyle | 8m 56s | branch-1 passed | | +0 :ok: | refguide | 4m 55s | branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect. | | +1 :green_heart: | shadedjars | 4m 2s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 4m 27s | branch-1 passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | javadoc | 5m 2s | branch-1 passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | +0 :ok: | spotbugs | 3m 28s | Used deprecated FindBugs config; considering switching to SpotBugs. | | +1 :green_heart: | findbugs | 18m 41s | branch-1 passed | ||| _ Patch Compile Tests _ | | +0 :ok: | mvndep | 0m 20s | Maven dependency ordering for patch | | +1 :green_heart: | mvninstall | 2m 40s | the patch passed | | +1 :green_heart: | compile | 2m 54s | the patch passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | javac | 2m 54s | the patch passed | | +1 :green_heart: | compile | 2m 43s | the patch passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | +1 :green_heart: | javac | 2m 43s | the patch passed | | +1 :green_heart: | checkstyle | 9m 13s | the patch passed | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +0 :ok: | refguide | 4m 22s | patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect. | | +1 :green_heart: | shadedjars | 4m 3s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | hadoopcheck | 6m 29s | Patch does not cause any errors with Hadoop 2.8.5 2.9.2. | | +1 :green_heart: | javadoc | 4m 2s | the patch passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | javadoc | 4m 44s | the patch passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | +1 :green_heart: | findbugs | 17m 22s | the patch passed | ||| _ Other Tests _ | | -1 :x: | unit | 199m 16s | root in the patch failed. | | +1 :green_heart: | asflicense | 2m 12s | The patch does not generate ASF License warnings. | | | | 336m 19s | | | 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-3857/1/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3857 | | Optional Tests | dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile refguide | | uname | Linux 0aaeee3177db 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 | /home/jenkins/jenkins-agent/workspace/Base-PreCommit-GitHub-PR_PR-3857/out/precommit/personality/provided.sh | | git revision | branch-1 / 0d214ff53e | | 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:Azul Systems, Inc.-1.7.0_272-b10 | | refguide | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3857/1/artifact/out/branch-site/book.html | | refguide | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3857/1/artifact/out/patch-site/book.html | | unit | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3857/1/artifact/out/
[GitHub] [hbase] Apache-HBase commented on pull request #3858: HBASE-26467 Fix bug for MemStoreLABImpl.forceCopyOfBigCellInto(Cell)
Apache-HBase commented on pull request #3858: URL: https://github.com/apache/hbase/pull/3858#issuecomment-973656633 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 27s | 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 13s | master passed | | +1 :green_heart: | checkstyle | 1m 5s | master passed | | +1 :green_heart: | spotbugs | 2m 7s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 3m 49s | the patch passed | | +1 :green_heart: | compile | 3m 10s | the patch passed | | +1 :green_heart: | javac | 3m 10s | the patch passed | | -0 :warning: | checkstyle | 1m 3s | hbase-server: The patch generated 1 new + 18 unchanged - 0 fixed = 19 total (was 18) | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +1 :green_heart: | hadoopcheck | 19m 17s | Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1. | | +1 :green_heart: | spotbugs | 2m 15s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | asflicense | 0m 16s | The patch does not generate ASF License warnings. | | | | 49m 9s | | | 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-3858/2/artifact/yetus-general-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3858 | | Optional Tests | dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux 7f38fa9e3eba 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / b2571df7ae | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | checkstyle | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3858/2/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-3858/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 #3852: HBASE-26458 Update Snapshot TTL doc
Apache-HBase commented on pull request #3852: URL: https://github.com/apache/hbase/pull/3852#issuecomment-973661579 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 6m 14s | 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 _ | | +0 :ok: | mvndep | 0m 31s | Maven dependency ordering for branch | | +1 :green_heart: | mvninstall | 4m 19s | master passed | | +1 :green_heart: | compile | 3m 0s | master passed | | +1 :green_heart: | shadedjars | 9m 8s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 3m 33s | master passed | ||| _ Patch Compile Tests _ | | +0 :ok: | mvndep | 0m 13s | Maven dependency ordering for patch | | +1 :green_heart: | mvninstall | 4m 15s | the patch passed | | +1 :green_heart: | compile | 3m 0s | the patch passed | | +1 :green_heart: | javac | 3m 0s | the patch passed | | +1 :green_heart: | shadedjars | 9m 9s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 3m 38s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 425m 50s | root in the patch passed. | | | | 475m 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-3852/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3852 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 8d50511c12e6 4.15.0-142-generic #146-Ubuntu SMP Tue Apr 13 01:11:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | dev-support/hbase-personality.sh | | git revision | master / b2571df7ae | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/2/testReport/ | | Max. process+thread count | 3927 (vs. ulimit of 3) | | modules | C: hbase-common hbase-client hbase-server . U: . | | Console output | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/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
[jira] [Commented] (HBASE-26421) Use HFileLink file to replace entire file‘s reference when splitting
[
https://issues.apache.org/jira/browse/HBASE-26421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17446265#comment-17446265
]
Hudson commented on HBASE-26421:
Results for branch branch-2.4
[build #241 on
builds.a.o|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/241/]:
(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.4/241/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/241/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/241/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/241/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}
> Use HFileLink file to replace entire file‘s reference when splitting
>
>
> Key: HBASE-26421
> URL: https://issues.apache.org/jira/browse/HBASE-26421
> Project: HBase
> Issue Type: Sub-task
>Reporter: Xiaolin Ha
>Assignee: Xiaolin Ha
>Priority: Major
> Fix For: 2.5.0, 3.0.0-alpha-2
>
>
> ++When splitting store files, if a file should be owned by only one child
> region, then there will be an entire file's reference in the child region. We
> can use HFileLink files, just like those in snapshot tables, to replace the
> reference files that refer to entire files.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei reassigned HBASE-26465:
Assignee: chenglei
> MemStoreLAB may be released early when its SegmentScanner is scanning
> -
>
> Key: HBASE-26465
> URL: https://issues.apache.org/jira/browse/HBASE-26465
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.8
>Reporter: chenglei
>Assignee: chenglei
>Priority: Critical
>
> HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
> {{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
> {{DefaultMemStore#snapshot}} which may be used by
> {{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
> {{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
> {{DefaultMemStore#snapshot}} may be released early when its
> {{SegmentScanner}} is scanning.
> Considering follow thread sequences:
> 1.The flush thread starts {{DefaultMemStore}} flushing after some cells have
> be added to {{DefaultMemStore}}.
> 2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
>{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
> 3.The scan thread starts and stopping after
> {{DefaultMemStore.snapshot.getAllSegments}} in
>{{DefaultMemStore#getScanners}},here the scan thread gets the
> {{DefaultMemStore#snapshot}} which is created by the flush thread.
> 4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
> {{DefaultMemStore#snapshot}},because the reference count of the corresponding
> {{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}}
> are recycled.
> 5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
> {{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
> reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunks}} in
> corresponding {{MemStoreLABImpl}} are recycled by step 4, and these
> {{Chunks}} may be overwritten by other write threads, which may cause serious
> problem.
> I simulate above case in my PR, and my Fix in the PR is as following:
> 1.Moving {{MemStore.clearSnapshot}} back under write lock of
> {{HStore#lock}}, because {{DefaultMemStore#getScanners}} is protected under
> the read lock of {{HStore#lock}}, so {{DefaultMemStore#getScanners}} and
>{{DefaultMemStore#clearSnapshot}} could not execute concurrently.
> 2. Introducing {{RefCnt}} into {{MemStoreLABImpl}} to replace old reference
> count, so checking and increasing or decreasing is done in atomicity and if
> there is illegal state in reference count, it would throw exception rather
> than corrupt data.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [hbase] Apache-HBase commented on pull request #3858: HBASE-26467 Fix bug for MemStoreLABImpl.forceCopyOfBigCellInto(Cell)
Apache-HBase commented on pull request #3858: URL: https://github.com/apache/hbase/pull/3858#issuecomment-973714887 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 3m 55s | 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 54s | master passed | | +1 :green_heart: | compile | 1m 14s | master passed | | +1 :green_heart: | shadedjars | 8m 17s | 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 25s | the patch passed | | +1 :green_heart: | compile | 1m 13s | the patch passed | | +1 :green_heart: | javac | 1m 13s | the patch passed | | +1 :green_heart: | shadedjars | 8m 12s | 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 | 138m 33s | hbase-server in the patch passed. | | | | 174m 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-3858/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3858 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 613c61d80117 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 / b2571df7ae | | Default Java | AdoptOpenJDK-11.0.10+9 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3858/2/testReport/ | | Max. process+thread count | 4017 (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-3858/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 #3858: HBASE-26467 Fix bug for MemStoreLABImpl.forceCopyOfBigCellInto(Cell)
Apache-HBase commented on pull request #3858: URL: https://github.com/apache/hbase/pull/3858#issuecomment-973715616 :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 | 3m 47s | master passed | | +1 :green_heart: | compile | 0m 59s | master passed | | +1 :green_heart: | shadedjars | 8m 20s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 0m 36s | master passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 3m 51s | the patch passed | | +1 :green_heart: | compile | 1m 1s | the patch passed | | +1 :green_heart: | javac | 1m 1s | the patch passed | | +1 :green_heart: | shadedjars | 8m 15s | 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 | 145m 47s | hbase-server in the patch passed. | | | | 176m 1s | | | 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-3858/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3858 | | Optional Tests | javac javadoc unit shadedjars compile | | uname | Linux 92365d72fb80 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 / b2571df7ae | | Default Java | AdoptOpenJDK-1.8.0_282-b08 | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3858/2/testReport/ | | Max. process+thread count | 4763 (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-3858/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] zhengzhuobinzzb commented on pull request #3858: HBASE-26467 Fix bug for MemStoreLABImpl.forceCopyOfBigCellInto(Cell)
zhengzhuobinzzb commented on pull request #3858: URL: https://github.com/apache/hbase/pull/3858#issuecomment-973723923 Hi, @Apache9 @apurtell @comnetwork @sunhelly Please review in your free time, Thank you ~~ -- 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-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
following line 1239 in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
{code:java}
1221private boolean updateStorefiles(List sfs, long snapshotId)
throws IOException {
1223this.lock.writeLock().lock();
1224 try {
1225 this.storeEngine.getStoreFileManager().insertNewFiles(sfs);
1226} finally {
1227 // We need the lock, as long as we are updating the storeFiles
1228 // or changing the memstore. Let us release it before calling
1229 // notifyChangeReadersObservers. See HBASE-4485 for a possible
1230 // deadlock scenario that could have happened if continue to hold
1231 // the lock.
1232 this.lock.writeLock().unlock();
1233 }
1234// We do not need to call clearSnapshot method inside the write lock.
1235// The clearSnapshot itself is thread safe, which can be called at the
same time with other
1236// memstore operations expect snapshot and clearSnapshot. And for these
two methods, in HRegion
1237// we can guarantee that there is only one onging flush, so they will
be no race.
1238if (snapshotId > 0) {
1239 this.memstore.clearSnapshot(snapshotId);
1240}
{code}
3.The scan thread starts and stopping after
{{DefaultMemStore.snapshot.getAllSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}} are
recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunks}} in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunks}}
may be overwritten by other write threads, which may cause serious problem.
I simulate above case in my PR, and my Fix in the PR is as following:
1.Moving {{MemStore.clearSnapshot}} back under write lock of {{HStore#lock}},
because {{DefaultMemStore#getScanners}} is protected under the read lock of
{{HStore#lock}}, so {{DefaultMemStore#getScanners}} and
{{DefaultMemStore#clearSnapshot}} could not execute concurrently.
2. Introducing {{RefCnt}} into {{MemStoreLABImpl}} to replace old reference
count, so checking and increasing or decreasing is done in atomicity and if
there is illegal state in reference count, it would throw exception rather
than corrupt data.
was:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
3.The scan thread starts and stopping after
{{DefaultMemStore.snapshot.getAllSegments}} in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}} are
recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunks}} in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunks}}
m
[jira] [Updated] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
following line 1238 in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
{code:java}
1221private boolean updateStorefiles(List sfs, long snapshotId)
throws IOException {
1222this.lock.writeLock().lock();
1223 try {
1224 this.storeEngine.getStoreFileManager().insertNewFiles(sfs);
1225} finally {
1226 // We need the lock, as long as we are updating the storeFiles
1227 // or changing the memstore. Let us release it before calling
1228 // notifyChangeReadersObservers. See HBASE-4485 for a possible
1229 // deadlock scenario that could have happened if continue to hold
1230 // the lock.
1231 this.lock.writeLock().unlock();
1232 }
1233// We do not need to call clearSnapshot method inside the write lock.
1234// The clearSnapshot itself is thread safe, which can be called at the
same time with other
1235// memstore operations expect snapshot and clearSnapshot. And for these
two methods, in HRegion
1236// we can guarantee that there is only one onging flush, so they will
be no race.
1237if (snapshotId > 0) {
1238 this.memstore.clearSnapshot(snapshotId);
1239}
..
{code}
3.The scan thread starts and stopping after
{{DefaultMemStore.snapshot.getAllSegments}} in following line 141 in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
{code:java}
138 public List getScanners(long readPt) throws IOException {
139List list = new ArrayList<>();
140addToScanners(getActive(), readPt, list);
141addToScanners(snapshot.getAllSegments(), readPt, list);
142return list;
143 }
{code}
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}},because the reference count of the corresponding
{{MemStoreLABImpl}} is 0, the Chunks in corresponding {{MemStoreLABImpl}} are
recycled.
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and increase the
reference count of the corresponding {{MemStoreLABImpl}}, but {{Chunks}} in
corresponding {{MemStoreLABImpl}} are recycled by step 4, and these {{Chunks}}
may be overwritten by other write threads, which may cause serious problem.
I simulate above case in my PR, and my Fix in the PR is as following:
1.Moving {{MemStore.clearSnapshot}} back under write lock of {{HStore#lock}},
because {{DefaultMemStore#getScanners}} is protected under the read lock of
{{HStore#lock}}, so {{DefaultMemStore#getScanners}} and
{{DefaultMemStore#clearSnapshot}} could not execute concurrently.
2. Introducing {{RefCnt}} into {{MemStoreLABImpl}} to replace old reference
count, so checking and increasing or decreasing is done in atomicity and if
there is illegal state in reference count, it would throw exception rather
than corrupt data.
was:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
following line 1239 in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
{code:java}
1221private boolean updateStorefiles(List sfs, long snapshotId)
throws IOException {
1223this.lock.writeLock().lock();
1224 try {
1225 this.storeEngine.getStoreFileManager().insertNewFiles(sfs);
1226} finally {
1227 // We need the lock, as long as we are updating the storeFiles
1228 // or changing the memstore. Let us release it before calling
1229 // notifyChangeReadersObservers. See HBASE-4485 for a possible
1230
[jira] [Updated] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
following line 1238 in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
{code:java}
1221private boolean updateStorefiles(List sfs, long snapshotId)
throws IOException {
1222this.lock.writeLock().lock();
1223 try {
1224 this.storeEngine.getStoreFileManager().insertNewFiles(sfs);
1225} finally {
1226 // We need the lock, as long as we are updating the storeFiles
1227 // or changing the memstore. Let us release it before calling
1228 // notifyChangeReadersObservers. See HBASE-4485 for a possible
1229 // deadlock scenario that could have happened if continue to hold
1230 // the lock.
1231 this.lock.writeLock().unlock();
1232 }
1233// We do not need to call clearSnapshot method inside the write lock.
1234// The clearSnapshot itself is thread safe, which can be called at the
same time with other
1235// memstore operations expect snapshot and clearSnapshot. And for these
two methods, in HRegion
1236// we can guarantee that there is only one onging flush, so they will
be no race.
1237if (snapshotId > 0) {
1238 this.memstore.clearSnapshot(snapshotId);
1239}
..
{code}
3.The scan thread starts and stopping after
{{DefaultMemStore.snapshot.getAllSegments}} in following line 141 in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
{code:java}
138 public List getScanners(long readPt) throws IOException {
139List list = new ArrayList<>();
140addToScanners(getActive(), readPt, list);
141addToScanners(snapshot.getAllSegments(), readPt, list);
142return list;
143 }
{code}
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}} in following line 253,because the reference count
of the corresponding {{MemStoreLABImpl}} is decreased to 0, the Chunks in
corresponding {{MemStoreLABImpl}} are recycled.
{code:java}
240 public void clearSnapshot(long id) throws UnexpectedStateException {
..
248Segment oldSnapshot = this.snapshot;
249if (!this.snapshot.isEmpty()) {
250 this.snapshot =
SegmentFactory.instance().createImmutableSegment(this.comparator);
251}
252this.snapshotId = NO_SNAPSHOT_ID;
253oldSnapshot.close();
254 }
{code}
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and invokes
{{MemStoreLABImpl.incScannerCount}} in line 281 to increase the reference count
, but here {{MemStoreLABImpl.incScannerCount}} does not check that the
reference count is already 0 and {{Chunks}} are recycled by step 4, so these
{{Chunks}} may be overwritten by other write threads, which may cause serious
problem.
{code:java}
280 public void incScannerCount() {
281 this.openScannerCount.incrementAndGet();
282 }
{code}
I simulate above case in my PR, and my Fix in the PR is as following:
1.Moving {{MemStore.clearSnapshot}} back under write lock of {{HStore#lock}},
because {{DefaultMemStore#getScanners}} is protected under the read lock of
{{HStore#lock}}, so {{DefaultMemStore#getScanners}} and
{{DefaultMemStore#clearSnapshot}} could not execute concurrently.
2. Introducing {{RefCnt}} into {{MemStoreLABImpl}} to replace old reference
count, so checking and increasing or decreasing is done in atomicity and if
there is illegal state in reference count, it would throw exception rather
than corrupt data.
was:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{Default
[jira] [Updated] (HBASE-26465) MemStoreLAB may be released early when its SegmentScanner is scanning
[
https://issues.apache.org/jira/browse/HBASE-26465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated HBASE-26465:
-
Description:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}}.
2.The flush thread stopping before {{DefaultMemStore#clearSnapshot}} in
following line 1238 in
{{HStore#updateStorefiles}} after completed flushing memStore to hfile.
{code:java}
1221private boolean updateStorefiles(List sfs, long snapshotId)
throws IOException {
1222this.lock.writeLock().lock();
1223 try {
1224 this.storeEngine.getStoreFileManager().insertNewFiles(sfs);
1225} finally {
1226 // We need the lock, as long as we are updating the storeFiles
1227 // or changing the memstore. Let us release it before calling
1228 // notifyChangeReadersObservers. See HBASE-4485 for a possible
1229 // deadlock scenario that could have happened if continue to hold
1230 // the lock.
1231 this.lock.writeLock().unlock();
1232 }
1233// We do not need to call clearSnapshot method inside the write lock.
1234// The clearSnapshot itself is thread safe, which can be called at the
same time with other
1235// memstore operations expect snapshot and clearSnapshot. And for these
two methods, in HRegion
1236// we can guarantee that there is only one onging flush, so they will
be no race.
1237if (snapshotId > 0) {
1238 this.memstore.clearSnapshot(snapshotId);
1239}
..
{code}
3.The scan thread starts and stopping after
{{DefaultMemStore.snapshot.getAllSegments}} in following line 141 in
{{DefaultMemStore#getScanners}},here the scan thread gets the
{{DefaultMemStore#snapshot}} which is created by the flush thread.
{code:java}
138 public List getScanners(long readPt) throws IOException {
139List list = new ArrayList<>();
140addToScanners(getActive(), readPt, list);
141addToScanners(snapshot.getAllSegments(), readPt, list);
142return list;
143 }
{code}
4.The flush thread continues {{DefaultMemStore#clearSnapshot}} and close
{{DefaultMemStore#snapshot}} in following line 253,because the reference count
of the corresponding {{MemStoreLABImpl}} is decreased to 0, the Chunks in
corresponding {{MemStoreLABImpl}} are recycled.
{code:java}
240 public void clearSnapshot(long id) throws UnexpectedStateException {
..
248Segment oldSnapshot = this.snapshot;
249if (!this.snapshot.isEmpty()) {
250 this.snapshot =
SegmentFactory.instance().createImmutableSegment(this.comparator);
251}
252this.snapshotId = NO_SNAPSHOT_ID;
253oldSnapshot.close();
254 }
{code}
5.The scan thread continues {{DefaultMemStore#getScanners}}, and create a
{{SegmentScanner}} for this {{DefaultMemStore#snapshot}}, and invokes
{{MemStoreLABImpl.incScannerCount}} in line 281 to increase the reference count
, but here {{MemStoreLABImpl.incScannerCount}} does not check that the
reference count is already 0 and {{Chunks}} are already recycled by step 4,
so these {{Chunks}} may be overwritten by other write threads when the
{{SegmentScanner}} is scanning, which may cause serious problem.
{code:java}
280 public void incScannerCount() {
281 this.openScannerCount.incrementAndGet();
282 }
{code}
I simulate above case in my PR, and my Fix in the PR is as following:
1.Moving {{MemStore.clearSnapshot}} back under write lock of {{HStore#lock}},
because {{DefaultMemStore#getScanners}} is protected under the read lock of
{{HStore#lock}}, so {{DefaultMemStore#getScanners}} and
{{DefaultMemStore#clearSnapshot}} could not execute concurrently.
2. Introducing {{RefCnt}} into {{MemStoreLABImpl}} to replace old reference
count, so checking and increasing or decreasing is done in atomicity and if
there is illegal state in reference count, it would throw exception rather
than corrupt data.
was:
HBASE-26144 moved {{MemStore.clearSnapshot}} out of write lock of
{{HStore#lock}}, but because {{MemStore.clearSnapshot}} closed
{{DefaultMemStore#snapshot}} which may be used by
{{DefaultMemStore#getScanners}}, when {{DefaultMemStore#getScanners}} and
{{MemStore}} flushing execute conurrently, {{MemStoreLAB}} used by
{{DefaultMemStore#snapshot}} may be released early when its {{SegmentScanner}}
is scanning.
Considering follow thread sequences:
1.The flush thread starts {{DefaultMemStore}} flushing after some cells have be
added to {{DefaultMemStore}
[GitHub] [hbase] Apache-HBase commented on pull request #3857: HBASE-26458 Add UNSET_SNAPSHOT_PROP and fix TTL defaulting
Apache-HBase commented on pull request #3857: URL: https://github.com/apache/hbase/pull/3857#issuecomment-973763285 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 37s | 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. | | -0 :warning: | test4tests | 0m 0s | The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. | ||| _ branch-1 Compile Tests _ | | +0 :ok: | mvndep | 2m 32s | Maven dependency ordering for branch | | +1 :green_heart: | mvninstall | 8m 37s | branch-1 passed | | +1 :green_heart: | compile | 2m 18s | branch-1 passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | compile | 2m 4s | branch-1 passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | +1 :green_heart: | checkstyle | 7m 58s | branch-1 passed | | +0 :ok: | refguide | 4m 11s | branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect. | | +1 :green_heart: | shadedjars | 3m 24s | branch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | javadoc | 3m 53s | branch-1 passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | javadoc | 4m 29s | branch-1 passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | +0 :ok: | spotbugs | 2m 59s | Used deprecated FindBugs config; considering switching to SpotBugs. | | +1 :green_heart: | findbugs | 16m 37s | branch-1 passed | ||| _ Patch Compile Tests _ | | +0 :ok: | mvndep | 0m 18s | Maven dependency ordering for patch | | +1 :green_heart: | mvninstall | 2m 18s | the patch passed | | +1 :green_heart: | compile | 2m 10s | the patch passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | javac | 2m 10s | the patch passed | | +1 :green_heart: | compile | 2m 4s | the patch passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | +1 :green_heart: | javac | 2m 4s | the patch passed | | +1 :green_heart: | checkstyle | 7m 51s | the patch passed | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +0 :ok: | refguide | 3m 9s | patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect. | | +1 :green_heart: | shadedjars | 3m 16s | patch has no errors when building our shaded downstream artifacts. | | +1 :green_heart: | hadoopcheck | 5m 25s | Patch does not cause any errors with Hadoop 2.8.5 2.9.2. | | +1 :green_heart: | javadoc | 3m 57s | the patch passed with JDK Azul Systems, Inc.-1.8.0_262-b19 | | +1 :green_heart: | javadoc | 4m 33s | the patch passed with JDK Azul Systems, Inc.-1.7.0_272-b10 | | +1 :green_heart: | findbugs | 17m 8s | the patch passed | ||| _ Other Tests _ | | +1 :green_heart: | unit | 193m 2s | root in the patch passed. | | +1 :green_heart: | asflicense | 2m 8s | The patch does not generate ASF License warnings. | | | | 309m 3s | | | 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-3857/2/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/3857 | | Optional Tests | dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile refguide | | uname | Linux a402bcadd989 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 | /home/jenkins/jenkins-agent/workspace/Base-PreCommit-GitHub-PR_PR-3857/out/precommit/personality/provided.sh | | git revision | branch-1 / 0d214ff53e | | 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:Azul Systems, Inc.-1.7.0_272-b10 | | refguide | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3857/2/artifact/out/branch-site/book.html | | refguide | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3857/2/artifact/out/patch-site/book.html | | Test Results | https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-
[jira] [Commented] (HBASE-25905) Shutdown of WAL stuck at waitForSafePoint
[
https://issues.apache.org/jira/browse/HBASE-25905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17446287#comment-17446287
]
Xiaolin Ha commented on HBASE-25905:
The problem can be caused by the scenario as follows,
1. The consumer of WAL enters AsyncFSWAL#syncFailed, it will set writer broken
and request roll writer, and also add all the unackedAppends back to the
toWriteAppends;
2. Writer rolls and new WAL created, new consumer executed, when calling
AsyncFSWAL#appendAndSync, add partial toWriteAppends to the writer, limited the
writer length to the WAL_BATCH_SIZE. So after the consume, there are still some
toWriteAppends and unackedAppends in the queue.
for (Iterator iter = toWriteAppends.iterator(); iter.hasNext();) {
FSWALEntry entry = iter.next();
boolean appended;
try {
appended = appendEntry(writer, entry);
} catch (IOException e) {
throw new AssertionError("should not happen", e);
}
newHighestProcessedAppendTxid = entry.getTxid();
iter.remove();
if (appended) {
// This is possible, when we fail to sync, we will add the
unackedAppends back to
// toWriteAppends, so here we may get an entry which is already in the
unackedAppends.
if (unackedAppends.isEmpty() || unackedAppends.peekLast().getTxid() <
entry.getTxid()) {
unackedAppends.addLast(entry);
}
if (writer.getLength() - fileLengthAtLastSync >= batchSize) {
break;
}
}
}
...
3. sync(writer) is called, then 'fileLengthAtLastSync = writer.getLength()',
private void sync(AsyncWriter writer) {
fileLengthAtLastSync = writer.getLength();
...
4. Regionserver abort(server.isAborted() is true), shutdown the wal factory,
enter the AsyncFSWAL#waitForSafePoint, waiting on ConditionObject
readyForRollingCond, and current state is waiting for roll, triggers a consumer,
just return without signal the readyForRollingCond, because current
fileLengthAtLastSync = writer.getLength() and unackedAppends is not empty,
if (waitingRoll(currentEpochAndState)) {
if (writer.getLength() > fileLengthAtLastSync) {
// issue a sync
sync(writer);
} else {
if (unackedAppends.isEmpty()) {
readyForRolling = true;
readyForRollingCond.signalAll();
}
}
return;
}
5. the thread calling sync(writer) in step 3 calls AsyncFSWAL#syncCompleted,
when calling trySetReadyForRolling, find that unackedAppends is not empty, so
just return without signal the readyForRollingCond,
private boolean trySetReadyForRolling() {
// Check without holding lock first. Usually we will just return here.
// waitingRoll is volatile and unacedEntries is only accessed inside event
loop so it is safe to
// check them outside the consumeLock.
if (!waitingRoll(epochAndState) || !unackedAppends.isEmpty()) {
return false;
}
...
6. Since the regionserver is aborted and last consumer has set
AsyncFSWAL#waitingRoll be true, each consumer will just return like step 4;
7. Since the shutdown of WAL keeps the rollWriterLock, roll wal will not happen;
8. The regionserver thread stuck at AsyncFSWAL#waitForSafePoint.
> Shutdown of WAL stuck at waitForSafePoint
> -
>
> Key: HBASE-25905
> URL: https://issues.apache.org/jira/browse/HBASE-25905
> Project: HBase
> Issue Type: Bug
> Components: regionserver, wal
>Affects Versions: 3.0.0-alpha-1, 2.0.0
>Reporter: Xiaolin Ha
>Assignee: Xiaolin Ha
>Priority: Critical
> Attachments: rs-jstack1, rs-jstack2, wal-stuck-error-logs.png
>
>
> We use the fan-out HDFS OutputStream and AsyncFSWAL on our clusters, but met
> the problem than RS can not exit completely for several hours util manual
> interventions.
> The two jstacks below show that the regionserver thread can waiting
> unlimitedly in both
> AsyncFSWAL#waitForSafePoint()
> {code:java}
> "regionserver/gh-data-hbase-finance08.mt/10.22.179.24:16020" #29 prio=5
> os_prio=0 tid=0x7fb2feb5c000 nid=0xa92b waiting on condition
> [0x7f9ccb992000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x7faea229a9d0> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
> at
> org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.waitForSafePoint(AsyncFSWAL.java:687)
> at
> org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.doShutdown(AsyncFSWAL.java:743)
>
[jira] [Comment Edited] (HBASE-25905) Shutdown of WAL stuck at waitForSafePoint
[
https://issues.apache.org/jira/browse/HBASE-25905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17446287#comment-17446287
]
Xiaolin Ha edited comment on HBASE-25905 at 11/19/21, 5:23 AM:
---
The problem can be caused by the scenario as follows,
1. The consumer of WAL enters AsyncFSWAL#syncFailed, it will set writer broken
and request roll writer, and also add all the unackedAppends back to the
toWriteAppends;
2. Writer rolls and new WAL created, new consumer executed, when calling
AsyncFSWAL#appendAndSync, add partial toWriteAppends to the writer, limited the
writer length to the WAL_BATCH_SIZE. So after the consume, there are still some
toWriteAppends and unackedAppends in the queue.
{code:java}
for (Iterator iter = toWriteAppends.iterator(); iter.hasNext();) {
FSWALEntry entry = iter.next();
boolean appended;
try {
appended = appendEntry(writer, entry);
} catch (IOException e) {
throw new AssertionError("should not happen", e);
}
newHighestProcessedAppendTxid = entry.getTxid();
iter.remove();
if (appended) {
// This is possible, when we fail to sync, we will add the
unackedAppends back to
// toWriteAppends, so here we may get an entry which is already in the
unackedAppends.
if (unackedAppends.isEmpty() || unackedAppends.peekLast().getTxid() <
entry.getTxid()) {
unackedAppends.addLast(entry);
}
if (writer.getLength() - fileLengthAtLastSync >= batchSize) {
break;
}
}
}
...{code}
3. sync(writer) is called, then 'fileLengthAtLastSync = writer.getLength()',
{code:java}
private void sync(AsyncWriter writer) {
fileLengthAtLastSync = writer.getLength();
... {code}
4. Regionserver abort(server.isAborted() is true), shutdown the wal factory,
enter the AsyncFSWAL#waitForSafePoint, waiting on ConditionObject
readyForRollingCond, and current state is waiting for roll, triggers a consumer,
just return without signal the readyForRollingCond, because current
fileLengthAtLastSync = writer.getLength() and unackedAppends is not empty,
{code:java}
if (waitingRoll(currentEpochAndState)) {
if (writer.getLength() > fileLengthAtLastSync) {
// issue a sync
sync(writer);
} else {
if (unackedAppends.isEmpty()) {
readyForRolling = true;
readyForRollingCond.signalAll();
}
}
return;
}
... {code}
5. the thread calling sync(writer) in step 3 calls AsyncFSWAL#syncCompleted,
when calling trySetReadyForRolling, find that unackedAppends is not empty, so
just return without signal the readyForRollingCond,
{code:java}
private boolean trySetReadyForRolling() {
// Check without holding lock first. Usually we will just return here.
// waitingRoll is volatile and unacedEntries is only accessed inside event
loop so it is safe to
// check them outside the consumeLock.
if (!waitingRoll(epochAndState) || !unackedAppends.isEmpty()) {
return false;
}
... {code}
6. Since the regionserver is aborted and last consumer has set
AsyncFSWAL#waitingRoll be true, each consumer will just return like step 4;
7. Since the shutdown of WAL keeps the rollWriterLock, roll wal will not happen;
8. The regionserver thread stuck at AsyncFSWAL#waitForSafePoint.
was (Author: xiaolin ha):
The problem can be caused by the scenario as follows,
1. The consumer of WAL enters AsyncFSWAL#syncFailed, it will set writer broken
and request roll writer, and also add all the unackedAppends back to the
toWriteAppends;
2. Writer rolls and new WAL created, new consumer executed, when calling
AsyncFSWAL#appendAndSync, add partial toWriteAppends to the writer, limited the
writer length to the WAL_BATCH_SIZE. So after the consume, there are still some
toWriteAppends and unackedAppends in the queue.
for (Iterator iter = toWriteAppends.iterator(); iter.hasNext();) {
FSWALEntry entry = iter.next();
boolean appended;
try {
appended = appendEntry(writer, entry);
} catch (IOException e) {
throw new AssertionError("should not happen", e);
}
newHighestProcessedAppendTxid = entry.getTxid();
iter.remove();
if (appended) {
// This is possible, when we fail to sync, we will add the
unackedAppends back to
// toWriteAppends, so here we may get an entry which is already in the
unackedAppends.
if (unackedAppends.isEmpty() || unackedAppends.peekLast().getTxid() <
entry.getTxid()) {
unackedAppends.addLast(entry);
}
if (writer.getLength() - fileLengthAtLastSync >= batchSize) {
break;
}
}
}
...
3. sync(writer) is called, then 'fileLengthAtLastSync = writer.getLength()',
private void sync(AsyncWriter writer) {
fileLengthAtLastSync = writer.ge
[jira] [Comment Edited] (HBASE-25905) Shutdown of WAL stuck at waitForSafePoint
[
https://issues.apache.org/jira/browse/HBASE-25905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17446287#comment-17446287
]
Xiaolin Ha edited comment on HBASE-25905 at 11/19/21, 5:26 AM:
---
The problem can be caused by the scenario as follows,
1. The consumer of WAL enters AsyncFSWAL#syncFailed, it will set writer broken
and request roll writer, and also add all the unackedAppends back to the
toWriteAppends;
2. Writer rolls and new WAL created, new consumer executed, when calling
AsyncFSWAL#appendAndSync, add partial toWriteAppends to the writer, limited the
writer length to the WAL_BATCH_SIZE. So after the consume, there are still some
toWriteAppends and unackedAppends in the queue.
{code:java}
for (Iterator iter = toWriteAppends.iterator(); iter.hasNext();) {
FSWALEntry entry = iter.next();
boolean appended;
try {
appended = appendEntry(writer, entry);
} catch (IOException e) {
throw new AssertionError("should not happen", e);
}
newHighestProcessedAppendTxid = entry.getTxid();
iter.remove();
if (appended) {
// This is possible, when we fail to sync, we will add the
unackedAppends back to
// toWriteAppends, so here we may get an entry which is already in the
unackedAppends.
if (unackedAppends.isEmpty() || unackedAppends.peekLast().getTxid() <
entry.getTxid()) {
unackedAppends.addLast(entry);
}
if (writer.getLength() - fileLengthAtLastSync >= batchSize) {
break;
}
}
}
...{code}
3. sync(writer) is called, then 'fileLengthAtLastSync = writer.getLength()',
{code:java}
private void sync(AsyncWriter writer) {
fileLengthAtLastSync = writer.getLength();
... {code}
4. the thread calling sync(writer) in step 3 calls AsyncFSWAL#syncCompleted,
when calling trySetReadyForRolling, find that unackedAppends is not empty, so
just return without signal the readyForRollingCond,
{code:java}
private boolean trySetReadyForRolling() {
// Check without holding lock first. Usually we will just return here.
// waitingRoll is volatile and unacedEntries is only accessed inside event
loop so it is safe to
// check them outside the consumeLock.
if (!waitingRoll(epochAndState) || !unackedAppends.isEmpty()) {
return false;
}
... {code}
5. Regionserver abort(server.isAborted() is true), shutdown the wal factory,
enter the AsyncFSWAL#waitForSafePoint, waiting on ConditionObject
readyForRollingCond, and current state is waiting for roll, triggers a consumer,
just return without signal the readyForRollingCond, because current
fileLengthAtLastSync = writer.getLength() and unackedAppends is not empty,
{code:java}
if (waitingRoll(currentEpochAndState)) {
if (writer.getLength() > fileLengthAtLastSync) {
// issue a sync
sync(writer);
} else {
if (unackedAppends.isEmpty()) {
readyForRolling = true;
readyForRollingCond.signalAll();
}
}
return;
}
... {code}
6. Since the regionserver is aborted and last consumer has set
AsyncFSWAL#waitingRoll be true, each consumer will just return like step 4;
7. Since the shutdown of WAL keeps the rollWriterLock, roll wal will not happen;
8. The regionserver thread stuck at AsyncFSWAL#waitForSafePoint.
was (Author: xiaolin ha):
The problem can be caused by the scenario as follows,
1. The consumer of WAL enters AsyncFSWAL#syncFailed, it will set writer broken
and request roll writer, and also add all the unackedAppends back to the
toWriteAppends;
2. Writer rolls and new WAL created, new consumer executed, when calling
AsyncFSWAL#appendAndSync, add partial toWriteAppends to the writer, limited the
writer length to the WAL_BATCH_SIZE. So after the consume, there are still some
toWriteAppends and unackedAppends in the queue.
{code:java}
for (Iterator iter = toWriteAppends.iterator(); iter.hasNext();) {
FSWALEntry entry = iter.next();
boolean appended;
try {
appended = appendEntry(writer, entry);
} catch (IOException e) {
throw new AssertionError("should not happen", e);
}
newHighestProcessedAppendTxid = entry.getTxid();
iter.remove();
if (appended) {
// This is possible, when we fail to sync, we will add the
unackedAppends back to
// toWriteAppends, so here we may get an entry which is already in the
unackedAppends.
if (unackedAppends.isEmpty() || unackedAppends.peekLast().getTxid() <
entry.getTxid()) {
unackedAppends.addLast(entry);
}
if (writer.getLength() - fileLengthAtLastSync >= batchSize) {
break;
}
}
}
...{code}
3. sync(writer) is called, then 'fileLengthAtLastSync = writer.getLength()',
{code:java}
private void sync(AsyncWriter writer) {
fileL
[jira] [Comment Edited] (HBASE-25905) Shutdown of WAL stuck at waitForSafePoint
[
https://issues.apache.org/jira/browse/HBASE-25905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17446287#comment-17446287
]
Xiaolin Ha edited comment on HBASE-25905 at 11/19/21, 5:27 AM:
---
The problem can be caused by the scenario as follows,
1. The consumer of WAL enters AsyncFSWAL#syncFailed, it will set writer broken
and request roll writer, and also add all the unackedAppends back to the
toWriteAppends;
2. Writer rolls and new WAL created, new consumer executed, when calling
AsyncFSWAL#appendAndSync, add partial toWriteAppends to the writer, limited the
writer length to the WAL_BATCH_SIZE. So after the consume, there are still some
toWriteAppends and unackedAppends in the queue.
{code:java}
for (Iterator iter = toWriteAppends.iterator(); iter.hasNext();) {
FSWALEntry entry = iter.next();
boolean appended;
try {
appended = appendEntry(writer, entry);
} catch (IOException e) {
throw new AssertionError("should not happen", e);
}
newHighestProcessedAppendTxid = entry.getTxid();
iter.remove();
if (appended) {
// This is possible, when we fail to sync, we will add the
unackedAppends back to
// toWriteAppends, so here we may get an entry which is already in the
unackedAppends.
if (unackedAppends.isEmpty() || unackedAppends.peekLast().getTxid() <
entry.getTxid()) {
unackedAppends.addLast(entry);
}
if (writer.getLength() - fileLengthAtLastSync >= batchSize) {
break;
}
}
}
...{code}
3. sync(writer) is called, then 'fileLengthAtLastSync = writer.getLength()',
{code:java}
private void sync(AsyncWriter writer) {
fileLengthAtLastSync = writer.getLength();
... {code}
4. the thread calling sync(writer) in step 3 calls AsyncFSWAL#syncCompleted,
when calling trySetReadyForRolling just return,
{code:java}
private boolean trySetReadyForRolling() {
// Check without holding lock first. Usually we will just return here.
// waitingRoll is volatile and unacedEntries is only accessed inside event
loop so it is safe to
// check them outside the consumeLock.
if (!waitingRoll(epochAndState) || !unackedAppends.isEmpty()) {
return false;
}
... {code}
5. Regionserver abort(server.isAborted() is true), shutdown the wal factory,
enter the AsyncFSWAL#waitForSafePoint, waiting on ConditionObject
readyForRollingCond, and current state is waiting for roll, triggers a consumer,
just return without signal the readyForRollingCond, because current
fileLengthAtLastSync = writer.getLength() and unackedAppends is not empty,
{code:java}
if (waitingRoll(currentEpochAndState)) {
if (writer.getLength() > fileLengthAtLastSync) {
// issue a sync
sync(writer);
} else {
if (unackedAppends.isEmpty()) {
readyForRolling = true;
readyForRollingCond.signalAll();
}
}
return;
}
... {code}
6. Since the regionserver is aborted and last consumer has set
AsyncFSWAL#waitingRoll be true, each consumer will just return like step 4;
7. Since the shutdown of WAL keeps the rollWriterLock, roll wal will not happen;
8. The regionserver thread stuck at AsyncFSWAL#waitForSafePoint.
was (Author: xiaolin ha):
The problem can be caused by the scenario as follows,
1. The consumer of WAL enters AsyncFSWAL#syncFailed, it will set writer broken
and request roll writer, and also add all the unackedAppends back to the
toWriteAppends;
2. Writer rolls and new WAL created, new consumer executed, when calling
AsyncFSWAL#appendAndSync, add partial toWriteAppends to the writer, limited the
writer length to the WAL_BATCH_SIZE. So after the consume, there are still some
toWriteAppends and unackedAppends in the queue.
{code:java}
for (Iterator iter = toWriteAppends.iterator(); iter.hasNext();) {
FSWALEntry entry = iter.next();
boolean appended;
try {
appended = appendEntry(writer, entry);
} catch (IOException e) {
throw new AssertionError("should not happen", e);
}
newHighestProcessedAppendTxid = entry.getTxid();
iter.remove();
if (appended) {
// This is possible, when we fail to sync, we will add the
unackedAppends back to
// toWriteAppends, so here we may get an entry which is already in the
unackedAppends.
if (unackedAppends.isEmpty() || unackedAppends.peekLast().getTxid() <
entry.getTxid()) {
unackedAppends.addLast(entry);
}
if (writer.getLength() - fileLengthAtLastSync >= batchSize) {
break;
}
}
}
...{code}
3. sync(writer) is called, then 'fileLengthAtLastSync = writer.getLength()',
{code:java}
private void sync(AsyncWriter writer) {
fileLengthAtLastSync = writer.getLength();
... {code}
4. the thread calling sync(writer)
[jira] [Comment Edited] (HBASE-25905) Shutdown of WAL stuck at waitForSafePoint
[
https://issues.apache.org/jira/browse/HBASE-25905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17446287#comment-17446287
]
Xiaolin Ha edited comment on HBASE-25905 at 11/19/21, 5:28 AM:
---
The problem can be caused by the scenario as follows,
1. The consumer of WAL enters AsyncFSWAL#syncFailed, it will set writer broken
and request roll writer, and also add all the unackedAppends back to the
toWriteAppends;
2. Writer rolls and new WAL created, new consumer executed, when calling
AsyncFSWAL#appendAndSync, add partial toWriteAppends to the writer, limited the
writer length to the WAL_BATCH_SIZE. So after the consume, there are still some
toWriteAppends and unackedAppends in the queue.
{code:java}
for (Iterator iter = toWriteAppends.iterator(); iter.hasNext();) {
FSWALEntry entry = iter.next();
boolean appended;
try {
appended = appendEntry(writer, entry);
} catch (IOException e) {
throw new AssertionError("should not happen", e);
}
newHighestProcessedAppendTxid = entry.getTxid();
iter.remove();
if (appended) {
// This is possible, when we fail to sync, we will add the
unackedAppends back to
// toWriteAppends, so here we may get an entry which is already in the
unackedAppends.
if (unackedAppends.isEmpty() || unackedAppends.peekLast().getTxid() <
entry.getTxid()) {
unackedAppends.addLast(entry);
}
if (writer.getLength() - fileLengthAtLastSync >= batchSize) {
break;
}
}
}
...{code}
3. sync(writer) is called, then 'fileLengthAtLastSync = writer.getLength()',
{code:java}
private void sync(AsyncWriter writer) {
fileLengthAtLastSync = writer.getLength();
... {code}
4. the thread calling sync(writer) in step 3 calls AsyncFSWAL#syncCompleted,
when calling trySetReadyForRolling just return,
{code:java}
private boolean trySetReadyForRolling() {
// Check without holding lock first. Usually we will just return here.
// waitingRoll is volatile and unacedEntries is only accessed inside event
loop so it is safe to
// check them outside the consumeLock.
if (!waitingRoll(epochAndState) || !unackedAppends.isEmpty()) {
return false;
}
... {code}
5. Regionserver abort(server.isAborted() is true), shutdown the wal factory,
enter the AsyncFSWAL#waitForSafePoint, waiting on ConditionObject
readyForRollingCond, and current state is waiting for roll, triggers a consumer,
just return without signal the readyForRollingCond, because current
fileLengthAtLastSync = writer.getLength() and unackedAppends is not empty,
{code:java}
if (waitingRoll(currentEpochAndState)) {
if (writer.getLength() > fileLengthAtLastSync) {
// issue a sync
sync(writer);
} else {
if (unackedAppends.isEmpty()) {
readyForRolling = true;
readyForRollingCond.signalAll();
}
}
return;
}
... {code}
6. Since the regionserver is aborted and last consumer has set
AsyncFSWAL#waitingRoll be true, each consumer will just return like step 5;
7. Since the shutdown of WAL keeps the rollWriterLock, roll wal will not happen;
8. The regionserver thread stuck at AsyncFSWAL#waitForSafePoint.
was (Author: xiaolin ha):
The problem can be caused by the scenario as follows,
1. The consumer of WAL enters AsyncFSWAL#syncFailed, it will set writer broken
and request roll writer, and also add all the unackedAppends back to the
toWriteAppends;
2. Writer rolls and new WAL created, new consumer executed, when calling
AsyncFSWAL#appendAndSync, add partial toWriteAppends to the writer, limited the
writer length to the WAL_BATCH_SIZE. So after the consume, there are still some
toWriteAppends and unackedAppends in the queue.
{code:java}
for (Iterator iter = toWriteAppends.iterator(); iter.hasNext();) {
FSWALEntry entry = iter.next();
boolean appended;
try {
appended = appendEntry(writer, entry);
} catch (IOException e) {
throw new AssertionError("should not happen", e);
}
newHighestProcessedAppendTxid = entry.getTxid();
iter.remove();
if (appended) {
// This is possible, when we fail to sync, we will add the
unackedAppends back to
// toWriteAppends, so here we may get an entry which is already in the
unackedAppends.
if (unackedAppends.isEmpty() || unackedAppends.peekLast().getTxid() <
entry.getTxid()) {
unackedAppends.addLast(entry);
}
if (writer.getLength() - fileLengthAtLastSync >= batchSize) {
break;
}
}
}
...{code}
3. sync(writer) is called, then 'fileLengthAtLastSync = writer.getLength()',
{code:java}
private void sync(AsyncWriter writer) {
fileLengthAtLastSync = writer.getLength();
... {code}
4. the thread calling sync(writer)
[GitHub] [hbase] sunhelly commented on pull request #3830: HBASE-26434 Compact L0 files for cold regions using StripeCompactionPolicy
sunhelly commented on pull request #3830: URL: https://github.com/apache/hbase/pull/3830#issuecomment-973769168 @Apache9 can you help review this PR at your convenience? 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-25905) Shutdown of WAL stuck at waitForSafePoint
[
https://issues.apache.org/jira/browse/HBASE-25905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaolin Ha updated HBASE-25905:
---
Description:
We use the fan-out HDFS OutputStream and AsyncFSWAL on our clusters, but met
the problem than RS can not exit completely for several hours util manual
interventions.
The two jstacks below show that the regionserver thread can waiting unlimitedly
in both
AsyncFSWAL#waitForSafePoint()
{code:java}
"regionserver/gh-data-hbase-finance08.mt/10.22.179.24:16020" #29 prio=5
os_prio=0 tid=0x7fb2feb5c000 nid=0xa92b waiting on condition
[0x7f9ccb992000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x7faea229a9d0> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
at
org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.waitForSafePoint(AsyncFSWAL.java:687)
at
org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.doShutdown(AsyncFSWAL.java:743)
at
org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL.shutdown(AbstractFSWAL.java:900)
at
org.apache.hadoop.hbase.wal.AbstractFSWALProvider.shutdown(AbstractFSWALProvider.java:182)
at
org.apache.hadoop.hbase.wal.RegionGroupingProvider.shutdown(RegionGroupingProvider.java:232)
at org.apache.hadoop.hbase.wal.WALFactory.shutdown(WALFactory.java:271)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.shutdownWAL(HRegionServer.java:1405)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:1147)
at java.lang.Thread.run(Thread.java:745)
{code}
and the log roller stuck at waiting for lock
{code:java}
"regionserver/gh-data-hbase-finance08.mt/10.22.179.24:16020.logRoller" #322
daemon prio=5 os_prio=0 tid=0x7fb2e11a4000 nid=0xa953 waiting on condition
[0x7f9cbd9f1000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x7faea1217048> (a
java.util.concurrent.locks.ReentrantLock$FairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at
java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
at
org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL.rollWriter(AbstractFSWAL.java:822)
at
org.apache.hadoop.hbase.wal.AbstractWALRoller$RollController.rollWal(AbstractWALRoller.java:269)
at
org.apache.hadoop.hbase.wal.AbstractWALRoller.run(AbstractWALRoller.java:186){code}
was:
We use the fan-out HDFS OutputStream and AsyncFSWAL on our clusters, but met
the problem than RS can not exit completely for several hours util manual
interventions.
The two jstacks below show that the regionserver thread can waiting unlimitedly
in both
AsyncFSWAL#waitForSafePoint()
{code:java}
"regionserver/gh-data-hbase-finance08.mt/10.22.179.24:16020" #29 prio=5
os_prio=0 tid=0x7fb2feb5c000 nid=0xa92b waiting on condition
[0x7f9ccb992000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x7faea229a9d0> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
at
org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.waitForSafePoint(AsyncFSWAL.java:687)
at
org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.doShutdown(AsyncFSWAL.java:743)
at
org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL.shutdown(AbstractFSWAL.java:900)
at
org.apache.hadoop.hbase.wal.AbstractFSWALProvider.shutdown(AbstractFSWALProvider.java:182)
at
org.apache.hadoop.hbase.wal.RegionGroupingProvider.shutdown(RegionGroupingProvider.java:232)
at org.apache.hadoop.hbase.wal.WALFactory.shutdown(WALFactory.java:271)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.shutdownWAL(HRegionServer.java:1405)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:1147)
at java.lang.Th
[jira] [Commented] (HBASE-25905) Shutdown of WAL stuck at waitForSafePoint
[
https://issues.apache.org/jira/browse/HBASE-25905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17446293#comment-17446293
]
Xiaolin Ha commented on HBASE-25905:
[~comnetwork] [~zhangduo] I think the key problem here is that the entries in
the writer content is not equal to the unackedAppends, only partial of
toWriteAppends will be appended to the writer and flushed in one consume.
> Shutdown of WAL stuck at waitForSafePoint
> -
>
> Key: HBASE-25905
> URL: https://issues.apache.org/jira/browse/HBASE-25905
> Project: HBase
> Issue Type: Bug
> Components: regionserver, wal
>Affects Versions: 3.0.0-alpha-1, 2.0.0
>Reporter: Xiaolin Ha
>Assignee: Xiaolin Ha
>Priority: Critical
> Attachments: rs-jstack1, rs-jstack2, wal-stuck-error-logs.png
>
>
> We use the fan-out HDFS OutputStream and AsyncFSWAL on our clusters, but met
> the problem than RS can not exit completely for several hours util manual
> interventions.
> The two jstacks below show that the regionserver thread can waiting
> unlimitedly in both
> AsyncFSWAL#waitForSafePoint()
> {code:java}
> "regionserver/gh-data-hbase-finance08.mt/10.22.179.24:16020" #29 prio=5
> os_prio=0 tid=0x7fb2feb5c000 nid=0xa92b waiting on condition
> [0x7f9ccb992000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x7faea229a9d0> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
> at
> org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.waitForSafePoint(AsyncFSWAL.java:687)
> at
> org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.doShutdown(AsyncFSWAL.java:743)
> at
> org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL.shutdown(AbstractFSWAL.java:900)
> at
> org.apache.hadoop.hbase.wal.AbstractFSWALProvider.shutdown(AbstractFSWALProvider.java:182)
> at
> org.apache.hadoop.hbase.wal.RegionGroupingProvider.shutdown(RegionGroupingProvider.java:232)
> at
> org.apache.hadoop.hbase.wal.WALFactory.shutdown(WALFactory.java:271)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.shutdownWAL(HRegionServer.java:1405)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:1147)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> and the log roller stuck at waiting for lock
> {code:java}
> "regionserver/gh-data-hbase-finance08.mt/10.22.179.24:16020.logRoller" #322
> daemon prio=5 os_prio=0 tid=0x7fb2e11a4000 nid=0xa953 waiting on
> condition [0x7f9cbd9f1000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x7faea1217048> (a
> java.util.concurrent.locks.ReentrantLock$FairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224)
> at
> java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at
> org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL.rollWriter(AbstractFSWAL.java:822)
> at
> org.apache.hadoop.hbase.wal.AbstractWALRoller$RollController.rollWal(AbstractWALRoller.java:269)
> at
> org.apache.hadoop.hbase.wal.AbstractWALRoller.run(AbstractWALRoller.java:186){code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (HBASE-26469) HBase shell has changed exit behavior
Sean Busbey created HBASE-26469:
---
Summary: HBase shell has changed exit behavior
Key: HBASE-26469
URL: https://issues.apache.org/jira/browse/HBASE-26469
Project: HBase
Issue Type: Bug
Components: shell
Affects Versions: 2.4.8, 2.5.0, 3.0.0-alpha-2
Reporter: Sean Busbey
The HBase shell has changed behavior in a way that breaks being able to exit
properly.
Two example scripts to act as stand ins for hbase shell scripts to "do
something simple then exit":
{code}
tmp % echo "list\nexit" > clean_exit.rb
tmp % echo "list\nexit 1" > error_exit.rb
{code}
Giving these two scripts is possible:
* passed as a cli argument
* via redirected stdin
Additionally the shell invocation can be:
* in the default compatibility mode
* with the "non interactive" flag that gives an exit code that reflects runtime
errors
I'll post logs of the details as attachments but here are some tables of the
exit codes.
The {{clean_exit.rb}} invocations ought to exit with success, exit code 0.
|| || 1.4.14 || 1.7.1 || 2.0.6 || 2.1.9 || 2.2.7 || 2.3.7 || 2.4.8 ||
master ||
| cli, default |0 |0 |0 |0 |0 |0 |1 |
1* |
| cli, -n | 0 |0 |0 |0 |0 |0 |1 |
hang |
| stdin, default | 0 |0 |0 |0 |0 |0 |0 |
0|
| stdin, -n | 1 |1 |1 |1 |1 |1 |1* |
1* |
The {{error_exit.rb}} invocation should return a non-zero exit code, unless
we're specifically trying to match a normal hbase shell session.
|| || 1.4.14 || 1.7.1 || 2.0.6 || 2.1.9 || 2.2.7 || 2.3.7 || 2.4.8 ||
master ||
| cli, default | 1 |1 |1 |1 |1 |1 |1* |
1* |
| cli, -n |1 |1 |1 |1 |1 |1 |1* |
hang |
| stdin, default | 0 |0 |0 |0 |0 |0 |0 |
0|
| stdin, -n | 1 |1 |1 |1 |1 |1 |1* |
1* |
In cases marked with * the error details are different.
The biggest concern are the new-to-2.4 non-zero exit code when we should have a
success and the hanging.
The former looks like this:
{code}
ERROR NoMethodError: private method `exit' called for nil:NilClass
{code}
The change in error details for the error exit script also shows this same
detail.
This behavior appears to be a side effect of HBASE-11686. As far as I can tell,
the IRB handling of 'exit' calls fail because we implement our own handling of
sessoins rather than rely on the intended session interface. We never set a
current session, and IRB's exit implementation presumes there will be one.
Running in debug shows this in a stacktrace:
{code}
Took 0.4563 seconds
ERROR NoMethodError: private method `exit' called for nil:NilClass
NoMethodError: private method `exit' called for nil:NilClass
irb_exit at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/extend-command.rb:30
evaluate at stdin:2
eval at org/jruby/RubyKernel.java:1048
evaluate at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/workspace.rb:85
eval_io at uri:classloader:/shell.rb:327
each_top_level_statement at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:246
loop at org/jruby/RubyKernel.java:1442
each_top_level_statement at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:232
catch at org/jruby/RubyKernel.java:1189
each_top_level_statement at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:231
eval_io at uri:classloader:/shell.rb:326
classpath:/jar-bootstrap.rb at classpath:/jar-bootstrap.rb:194
exception_handler at uri:classloader:/shell.rb:339
at classpath:/jar-bootstrap.rb:194
{code}
And in our version of IRB (0.9.6) [line 30 for
extend-commands|https://github.com/ruby/irb/blob/v0.9.6/lib/irb/extend-command.rb#L30]
corresponds to this code:
{code}
# Quits the current irb context
#
# +ret+ is the optional signal or message to send to Context#exit
#
# Same as IRB.CurrentContext.exit.
def irb_exit(ret = 0)
irb_context.exit(ret)
end
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (HBASE-26469) HBase shell has changed exit behavior
[
https://issues.apache.org/jira/browse/HBASE-26469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-26469:
Attachment: hbase-2.3.7-exit-behavior.log
hbase-2.2.7-exit-behavior.log
hbase-2.1.9-exit-behavior.log
hbase-2.0.6-exit-behavior.log
hbase-1.4.14-exit-behavior.log
hbase-1.7.1-exit-behavior.log
hbase-3.0.0-alpha-2-exit-behavior.log
hbase-2.4.8-exit-behavior.log
> HBase shell has changed exit behavior
> -
>
> Key: HBASE-26469
> URL: https://issues.apache.org/jira/browse/HBASE-26469
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 2.5.0, 3.0.0-alpha-2, 2.4.8
>Reporter: Sean Busbey
>Priority: Critical
> Attachments: hbase-1.4.14-exit-behavior.log,
> hbase-1.7.1-exit-behavior.log, hbase-2.0.6-exit-behavior.log,
> hbase-2.1.9-exit-behavior.log, hbase-2.2.7-exit-behavior.log,
> hbase-2.3.7-exit-behavior.log, hbase-2.4.8-exit-behavior.log,
> hbase-3.0.0-alpha-2-exit-behavior.log
>
>
> The HBase shell has changed behavior in a way that breaks being able to exit
> properly.
> Two example scripts to act as stand ins for hbase shell scripts to "do
> something simple then exit":
> {code}
> tmp % echo "list\nexit" > clean_exit.rb
> tmp % echo "list\nexit 1" > error_exit.rb
> {code}
> Giving these two scripts is possible:
> * passed as a cli argument
> * via redirected stdin
> Additionally the shell invocation can be:
> * in the default compatibility mode
> * with the "non interactive" flag that gives an exit code that reflects
> runtime errors
> I'll post logs of the details as attachments but here are some tables of the
> exit codes.
> The {{clean_exit.rb}} invocations ought to exit with success, exit code 0.
> || || 1.4.14 || 1.7.1 || 2.0.6 || 2.1.9 || 2.2.7 || 2.3.7 || 2.4.8
> || master ||
> | cli, default |0 |0 |0 |0 |0 |0 |1 |
>1* |
> | cli, -n | 0 |0 |0 |0 |0 |0 |1 |
> hang |
> | stdin, default | 0 |0 |0 |0 |0 |0 |0 |
>0|
> | stdin, -n | 1 |1 |1 |1 |1 |1 |1* |
>1* |
> The {{error_exit.rb}} invocation should return a non-zero exit code, unless
> we're specifically trying to match a normal hbase shell session.
> || || 1.4.14 || 1.7.1 || 2.0.6 || 2.1.9 || 2.2.7 || 2.3.7 || 2.4.8 ||
> master ||
> | cli, default | 1 |1 |1 |1 |1 |1 |1* |
> 1* |
> | cli, -n |1 |1 |1 |1 |1 |1 |1* |
> hang |
> | stdin, default | 0 |0 |0 |0 |0 |0 |0 |
> 0|
> | stdin, -n | 1 |1 |1 |1 |1 |1 |1* |
> 1* |
> In cases marked with * the error details are different.
> The biggest concern are the new-to-2.4 non-zero exit code when we should have
> a success and the hanging.
> The former looks like this:
> {code}
> ERROR NoMethodError: private method `exit' called for nil:NilClass
> {code}
> The change in error details for the error exit script also shows this same
> detail.
> This behavior appears to be a side effect of HBASE-11686. As far as I can
> tell, the IRB handling of 'exit' calls fail because we implement our own
> handling of sessoins rather than rely on the intended session interface. We
> never set a current session, and IRB's exit implementation presumes there
> will be one.
> Running in debug shows this in a stacktrace:
> {code}
> Took 0.4563 seconds
> ERROR NoMethodError: private method `exit' called for nil:NilClass
> NoMethodError: private method `exit' called for nil:NilClass
> irb_exit at
> uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/extend-command.rb:30
> evaluate at stdin:2
> eval at org/jruby/RubyKernel.java:1048
> evaluate at
> uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/workspace.rb:85
> eval_io at uri:classloader:/shell.rb:327
> each_top_level_statement at
> uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:246
> loop at org/jruby/RubyKernel.java:1442
> each_top_level_statement at
> uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:232
> catch at org/jruby/RubyKernel.java:1189
> each_top_level_statement at
> uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:231
> eval_io at uri:classloader:/shell.rb:326
> classpath:/jar-bootstrap.rb at classpath:/jar-bootstrap.rb:194
> excep
[jira] [Updated] (HBASE-26421) Use HFileLink file to replace entire file‘s reference when splitting
[ https://issues.apache.org/jira/browse/HBASE-26421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-26421: --- Parent: (was: HBASE-25302) Issue Type: Improvement (was: Sub-task) > Use HFileLink file to replace entire file‘s reference when splitting > > > Key: HBASE-26421 > URL: https://issues.apache.org/jira/browse/HBASE-26421 > Project: HBase > Issue Type: Improvement >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > Fix For: 2.5.0, 3.0.0-alpha-2 > > > ++When splitting store files, if a file should be owned by only one child > region, then there will be an entire file's reference in the child region. We > can use HFileLink files, just like those in snapshot tables, to replace the > reference files that refer to entire files. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (HBASE-25322) Redundant Reference file in bottom region of split
[ https://issues.apache.org/jira/browse/HBASE-25322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-25322: --- Priority: Minor (was: Blocker) > Redundant Reference file in bottom region of split > -- > > Key: HBASE-25322 > URL: https://issues.apache.org/jira/browse/HBASE-25322 > Project: HBase > Issue Type: Bug >Affects Versions: 3.0.0-alpha-2 >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Minor > Fix For: 3.0.0-alpha-2, 2.4.9 > > > When we split a region ranges from (,), the bottom region should contain keys > of(,split key), and the top region should contain keys of [split key, ). > Currently, if we do the following operations: > # put rowkeys 100,101,102,103,104,105 to a table, and flush the memstore to > make a hfile with rowkeys 100,101,102,103,104,105; > # put rowkeys 200,201,202,203,204,205 to the table, and flush the memstore > to make a hfile with rowkeys 200,201,202,203,204,205; > # split the table region, using split key 200; > # then the bottom region will has two Reference files, while the top region > only has one. > But we expect the bottom region has only one Reference file as the the top > region. > That's because when generating Reference files in child region, the bottom > region used the `PrivateCellUtil.createLastOnRow(splitRow)` cell to compare > to first keys in the hfiles, while the top region used > `PrivateCellUtil.createFirstOnRow(splitRow)` cell to compare to last keys in > the hfiles. > `LastOnRow(splitRow)` means the maximum row generated by the split row, while > `FirstOnRow(splitRow)` means the minimus row generated by the split row. The > split row should be in the top region. And we should use > `FirstOnRow(splitRow)` compare to hfile first and last keys in both bottom > and top region. > Though the redundant Reference file will not be read by the bottom region, > the compaction of the redundant Reference file will result in empty file if > only this redundant Reference file participates in a compaction. > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (HBASE-25322) Redundant Reference file in bottom region of split
[ https://issues.apache.org/jira/browse/HBASE-25322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-25322: --- Parent: (was: HBASE-25302) Issue Type: Bug (was: Sub-task) > Redundant Reference file in bottom region of split > -- > > Key: HBASE-25322 > URL: https://issues.apache.org/jira/browse/HBASE-25322 > Project: HBase > Issue Type: Bug >Affects Versions: 3.0.0-alpha-2 >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Blocker > Fix For: 3.0.0-alpha-2, 2.4.9 > > > When we split a region ranges from (,), the bottom region should contain keys > of(,split key), and the top region should contain keys of [split key, ). > Currently, if we do the following operations: > # put rowkeys 100,101,102,103,104,105 to a table, and flush the memstore to > make a hfile with rowkeys 100,101,102,103,104,105; > # put rowkeys 200,201,202,203,204,205 to the table, and flush the memstore > to make a hfile with rowkeys 200,201,202,203,204,205; > # split the table region, using split key 200; > # then the bottom region will has two Reference files, while the top region > only has one. > But we expect the bottom region has only one Reference file as the the top > region. > That's because when generating Reference files in child region, the bottom > region used the `PrivateCellUtil.createLastOnRow(splitRow)` cell to compare > to first keys in the hfiles, while the top region used > `PrivateCellUtil.createFirstOnRow(splitRow)` cell to compare to last keys in > the hfiles. > `LastOnRow(splitRow)` means the maximum row generated by the split row, while > `FirstOnRow(splitRow)` means the minimus row generated by the split row. The > split row should be in the top region. And we should use > `FirstOnRow(splitRow)` compare to hfile first and last keys in both bottom > and top region. > Though the redundant Reference file will not be read by the bottom region, > the compaction of the redundant Reference file will result in empty file if > only this redundant Reference file participates in a compaction. > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (HBASE-25322) Redundant Reference file in bottom region of split
[ https://issues.apache.org/jira/browse/HBASE-25322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-25322: --- Affects Version/s: 2.0.0 3.0.0-alpha-1 (was: 3.0.0-alpha-2) > Redundant Reference file in bottom region of split > -- > > Key: HBASE-25322 > URL: https://issues.apache.org/jira/browse/HBASE-25322 > Project: HBase > Issue Type: Bug >Affects Versions: 3.0.0-alpha-1, 2.0.0 >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Minor > Fix For: 3.0.0-alpha-2, 2.4.9 > > > When we split a region ranges from (,), the bottom region should contain keys > of(,split key), and the top region should contain keys of [split key, ). > Currently, if we do the following operations: > # put rowkeys 100,101,102,103,104,105 to a table, and flush the memstore to > make a hfile with rowkeys 100,101,102,103,104,105; > # put rowkeys 200,201,202,203,204,205 to the table, and flush the memstore > to make a hfile with rowkeys 200,201,202,203,204,205; > # split the table region, using split key 200; > # then the bottom region will has two Reference files, while the top region > only has one. > But we expect the bottom region has only one Reference file as the the top > region. > That's because when generating Reference files in child region, the bottom > region used the `PrivateCellUtil.createLastOnRow(splitRow)` cell to compare > to first keys in the hfiles, while the top region used > `PrivateCellUtil.createFirstOnRow(splitRow)` cell to compare to last keys in > the hfiles. > `LastOnRow(splitRow)` means the maximum row generated by the split row, while > `FirstOnRow(splitRow)` means the minimus row generated by the split row. The > split row should be in the top region. And we should use > `FirstOnRow(splitRow)` compare to hfile first and last keys in both bottom > and top region. > Though the redundant Reference file will not be read by the bottom region, > the compaction of the redundant Reference file will result in empty file if > only this redundant Reference file participates in a compaction. > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (HBASE-26425) Try to rebuild the stripes in child regions to improve compaction efficiency
[ https://issues.apache.org/jira/browse/HBASE-26425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-26425: --- Parent: (was: HBASE-25302) Issue Type: Improvement (was: Sub-task) > Try to rebuild the stripes in child regions to improve compaction efficiency > > > Key: HBASE-26425 > URL: https://issues.apache.org/jira/browse/HBASE-26425 > Project: HBase > Issue Type: Improvement >Reporter: Xiaolin Ha >Priority: Major > > This is an issue to improve the old rebuild stripes logic when loading files. > And this issue is not necessary for the umbrella. -- This message was sent by Atlassian Jira (v8.20.1#820001)
