[jira] [Resolved] (HBASE-28080) correct span name in AbstractRpcBasedConnectionRegistry#getActiveMaster
[
https://issues.apache.org/jira/browse/HBASE-28080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-28080.
---
Fix Version/s: 3.0.0-beta-1
(was: 4.0.0-alpha-1)
Hadoop Flags: Reviewed
Resolution: Fixed
Pushed to master and branch-3.
Thanks [~frostruan] for contributing!
> correct span name in AbstractRpcBasedConnectionRegistry#getActiveMaster
> ---
>
> Key: HBASE-28080
> URL: https://issues.apache.org/jira/browse/HBASE-28080
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 3.0.0-alpha-4
>Reporter: ruanhui
>Assignee: ruanhui
>Priority: Trivial
> Fix For: 3.0.0-beta-1
>
>
> It looks like that the span name does not correspond to what is actually done.
>
> public CompletableFuture getActiveMaster() {
> return tracedFuture(
> () -> this
> . call(
> (c, s, d) -> s.getActiveMaster(c,
> GetActiveMasterRequest.getDefaultInstance(), d),
> GetActiveMasterResponse::hasServerName, "getActiveMaster()")
> .thenApply(resp -> ProtobufUtil.toServerName(resp.getServerName())),
> getClass().getSimpleName() + ".getClusterId");
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (HBASE-28080) correct span name in AbstractRpcBasedConnectionRegistry#getActiveMaster
ruanhui created HBASE-28080:
---
Summary: correct span name in
AbstractRpcBasedConnectionRegistry#getActiveMaster
Key: HBASE-28080
URL: https://issues.apache.org/jira/browse/HBASE-28080
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 3.0.0-alpha-4
Reporter: ruanhui
Assignee: ruanhui
Fix For: 4.0.0-alpha-1
It looks like that the span name does not correspond to what is actually done.
public CompletableFuture getActiveMaster() {
return tracedFuture(
() -> this
. call(
(c, s, d) -> s.getActiveMaster(c, GetActiveMasterRequest.getDefaultInstance(),
d),
GetActiveMasterResponse::hasServerName, "getActiveMaster()")
.thenApply(resp -> ProtobufUtil.toServerName(resp.getServerName())),
getClass().getSimpleName() + ".getClusterId");
}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (HBASE-28079) Unhandled TableExistsException and NamespaceExistException in BackupSystemTable
Bryan Beaudreault created HBASE-28079:
-
Summary: Unhandled TableExistsException and
NamespaceExistException in BackupSystemTable
Key: HBASE-28079
URL: https://issues.apache.org/jira/browse/HBASE-28079
Project: HBase
Issue Type: Bug
Reporter: Bryan Beaudreault
Most backup-related operations instantiate a BackupSystemTable object. The
first thing it does is check that the {{backup}} namespace and backup-related
tables exist, and create them if not. One way in which this can be triggered is
via LoadIncrementalHFiles, which can load files with a configurable number of
threads. When bulkLoadHFile is called, a preCommitHFile hook is triggered which
does the above. With a certain level of concurrency, one can easily trigger a
race condition on creating the namespace or tables. This exception bubbles up
and fails the bulkload.
We should catch TableExistsException and NamespaceExistException in
BackupSystemTable initialization so that these do not cause client pain.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (HBASE-28078) Update tech details of backup
Dieter De Paepe created HBASE-28078: --- Summary: Update tech details of backup Key: HBASE-28078 URL: https://issues.apache.org/jira/browse/HBASE-28078 Project: HBase Issue Type: Task Reporter: Dieter De Paepe The [technical details|https://hbase.apache.org/book.html#br.technical.details] of HBase backup mention that the backup works by copying WALs which are converted to HFiles during the restore process. However, the code seems to imply that WALs are already converted to HFiles during the backup process. (See IncrementalTableBackupClient#convertWALsToHFiles.) I suspect the docs still describe the old behavior, which (I suspect) was changed in HBase-14141. Knowing this also confirms that bulk-imported HFiles are also backed-up - something I managed to test with experimentation, but wasn't explained in the backup docs. In short, this section in the docs requires an update. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28077) Limit the maximum allocation when reading an HFileBlock
Nick Dimiduk created HBASE-28077:
Summary: Limit the maximum allocation when reading an HFileBlock
Key: HBASE-28077
URL: https://issues.apache.org/jira/browse/HBASE-28077
Project: HBase
Issue Type: Improvement
Components: regionserver
Reporter: Nick Dimiduk
During PR discussion on HBASE-28065 we observe that the value of
{{onDiskSizeWithoutHeader}} is read and used before its portion of an HFile has
had its checksum validated. A method parameter is also provided which is used
when the caller knows what size to expect based on some other source. While
there are guards in place that limit the range of values this field can take,
that range remains large, something like {{[33,Integer.MAX_VALUE)}}. We propose
further limiting the range of this value to safeguard the region server from an
excessively large allocation.
Conversation is in https://github.com/apache/hbase/pull/5384/files#r1322947549
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (HBASE-28008) Add support for tcnative
[ https://issues.apache.org/jira/browse/HBASE-28008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Beaudreault resolved HBASE-28008. --- Fix Version/s: 2.6.0 3.0.0-beta-1 Release Note: If a properly shaded netty-tcnative is found on the classpath, hbase will automatically pick it up for use in accelerating TLS handling. Properly shaded means relocated to prefix with org.apache.hbase.thirdparty Assignee: Bryan Beaudreault Resolution: Fixed Pushed to master, branch-3, and branch-2. Thanks [~andor] and [~zhangduo] for the reviews! > Add support for tcnative > > > Key: HBASE-28008 > URL: https://issues.apache.org/jira/browse/HBASE-28008 > Project: HBase > Issue Type: Improvement >Reporter: Bryan Beaudreault >Assignee: Bryan Beaudreault >Priority: Major > Labels: tls > Fix For: 2.6.0, 3.0.0-beta-1 > > > In investigating HBASE-27947, tcnative can make a big impact on throughput > over built-in jdk SSL support. We need three things to make it work: > # In X509Util, if Openssl.isAvailable() (meaning tcnative is on the > classpath): > ## Use SslProvider.OPENSSL_REFCNT > ## Update default ciphers to remove CBC ciphers, which do not work with > tcnative. We can either pull the ciphers from > OpenSsl.availableJavaCipherSuites() or simply use the default GCM ciphers we > already have defined. > # Our netty is shaded, so one can't simply put the tcnative jar on the > classpath. We might need to provide an hbase-shaded-netty-tcnative module > which one can optionally include in their deployment. We will have to decide > which of the many tcnative modules to provide a shaded version for. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28075) [hbase-thirdparty] Add shaded netty tcnative module
Bryan Beaudreault created HBASE-28075: - Summary: [hbase-thirdparty] Add shaded netty tcnative module Key: HBASE-28075 URL: https://issues.apache.org/jira/browse/HBASE-28075 Project: HBase Issue Type: Sub-task Reporter: Bryan Beaudreault >From HBASE-28008, we need to provide some default module that includes shaded >netty-tcnative so that users can easily get deployed with it if they want to. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (HBASE-28074) Bump gitpython from 3.1.34 to 3.1.35 in /dev-support/flaky-tests
[ https://issues.apache.org/jira/browse/HBASE-28074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-28074. --- Hadoop Flags: Reviewed Resolution: Fixed > Bump gitpython from 3.1.34 to 3.1.35 in /dev-support/flaky-tests > > > Key: HBASE-28074 > URL: https://issues.apache.org/jira/browse/HBASE-28074 > Project: HBase > Issue Type: Task > Components: dependabot, scripts, security >Reporter: Duo Zhang >Priority: Major > Fix For: 2.6.0, 2.4.18, 2.5.6, 3.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (HBASE-28073) Bump gitpython from 3.1.32 to 3.1.35 in /dev-support/git-jira-release-audit
[ https://issues.apache.org/jira/browse/HBASE-28073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-28073. --- Hadoop Flags: Reviewed Resolution: Fixed > Bump gitpython from 3.1.32 to 3.1.35 in /dev-support/git-jira-release-audit > --- > > Key: HBASE-28073 > URL: https://issues.apache.org/jira/browse/HBASE-28073 > Project: HBase > Issue Type: Task > Components: dependabot, scripts, security >Reporter: Duo Zhang >Priority: Major > Fix For: 4.0.0-alpha-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28074) Bump gitpython from 3.1.34 to 3.1.35 in /dev-support/flaky-tests
Duo Zhang created HBASE-28074: - Summary: Bump gitpython from 3.1.34 to 3.1.35 in /dev-support/flaky-tests Key: HBASE-28074 URL: https://issues.apache.org/jira/browse/HBASE-28074 Project: HBase Issue Type: Task Components: dependabot, scripts, security Reporter: Duo Zhang Fix For: 2.6.0, 2.4.18, 2.5.6, 3.0.0-beta-1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (HBASE-28072) Bump gitpython from 3.1.32 to 3.1.34 in /dev-support/flaky-tests
[ https://issues.apache.org/jira/browse/HBASE-28072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-28072. --- Resolution: Fixed > Bump gitpython from 3.1.32 to 3.1.34 in /dev-support/flaky-tests > > > Key: HBASE-28072 > URL: https://issues.apache.org/jira/browse/HBASE-28072 > Project: HBase > Issue Type: Task > Components: dependabot, scripts, security >Reporter: Duo Zhang >Priority: Major > Fix For: 2.6.0, 2.4.18, 2.5.6, 3.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28073) Bump gitpython from 3.1.32 to 3.1.34 in /dev-support/git-jira-release-audit
Duo Zhang created HBASE-28073: - Summary: Bump gitpython from 3.1.32 to 3.1.34 in /dev-support/git-jira-release-audit Key: HBASE-28073 URL: https://issues.apache.org/jira/browse/HBASE-28073 Project: HBase Issue Type: Task Components: dependabot, scripts, security Reporter: Duo Zhang Fix For: 4.0.0-alpha-1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28072) Bump gitpython from 3.1.32 to 3.1.34 in /dev-support/flaky-tests
Duo Zhang created HBASE-28072: - Summary: Bump gitpython from 3.1.32 to 3.1.34 in /dev-support/flaky-tests Key: HBASE-28072 URL: https://issues.apache.org/jira/browse/HBASE-28072 Project: HBase Issue Type: Task Components: dependabot, scripts, security Reporter: Duo Zhang Fix For: 2.6.0, 2.4.18, 2.5.6, 3.0.0-beta-1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
