[jira] [Resolved] (HBASE-28305) Add "Uncompressed StoreFileSize" column to the table.jsp
[ https://issues.apache.org/jira/browse/HBASE-28305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-28305. --- Fix Version/s: 2.6.0 3.0.0-beta-2 Hadoop Flags: Reviewed Resolution: Fixed Pushed to branch-2.6+. Thanks [~haosen chen] for contributing! > Add "Uncompressed StoreFileSize" column to the table.jsp > > > Key: HBASE-28305 > URL: https://issues.apache.org/jira/browse/HBASE-28305 > Project: HBase > Issue Type: Improvement > Components: UI >Reporter: haosen chen >Assignee: haosen chen >Priority: Minor > Fix For: 2.6.0, 3.0.0-beta-2 > > Attachments: HBASE-28305-2.png, HBASE-28305.png > > > Currently, HBase Web UI can only see the uncompressed StoreFile size of each > Region on the Region Server page, but sometimes we also hope to see this > information on the table details page, which can help analyze the data > distribution of each table. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (HBASE-28312) The bad auth exception can not be passed to client rpc calls properly
[ https://issues.apache.org/jira/browse/HBASE-28312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-28312. --- Fix Version/s: 2.6.0 2.4.18 2.5.8 3.0.0-beta-2 Hadoop Flags: Reviewed Resolution: Fixed Pushed to all active branches. Thanks [~bbeaudreault] for reviewing! > The bad auth exception can not be passed to client rpc calls properly > - > > Key: HBASE-28312 > URL: https://issues.apache.org/jira/browse/HBASE-28312 > Project: HBase > Issue Type: Bug > Components: Client, rpc >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.6.0, 2.4.18, 2.5.8, 3.0.0-beta-2 > > > Found this when implementing HBASE-25051. > Basically there are 2 problems: > # IPCUtil.isFatalConnectionException only checks whether class name matches, > so if we use a sub class for FatalConnectionException, it will return false > which makes the logic incorrect. > # In BlockingRpcConnection, we will first check whether there is a call with > the id but since we will pass -1 as call id for bad preamble header, we will > return earlier without actually checking the error response. > This will not introduce big trouble in production as the call will still fail > with connection closed exception, but still worth to fix, anyway. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (HBASE-28306) Add property to customize Version information
[
https://issues.apache.org/jira/browse/HBASE-28306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Beaudreault resolved HBASE-28306.
---
Fix Version/s: 2.6.0
2.5.8
3.0.0-beta-2
Release Note: Added a new build property -Dversioninfo.version which can
be used to influence the generated Version.java class in custom build
scenarios. The version specified will show up in the HMaster UI and also have
implications on various version-related checks. This is an advanced usage
property and it's recommended not to stray too far from the default format of
major.minor.patch-suffix.
Resolution: Fixed
Pushed to all active release lines. Thanks [~zhangduo] for review!
> Add property to customize Version information
> -
>
> Key: HBASE-28306
> URL: https://issues.apache.org/jira/browse/HBASE-28306
> Project: HBase
> Issue Type: Improvement
>Reporter: Bryan Beaudreault
>Assignee: Bryan Beaudreault
>Priority: Major
> Fix For: 2.6.0, 2.5.8, 3.0.0-beta-2
>
>
> In hbase-common we generate Version.java using the ${project.version}
> property. In some custom builds, it may be necessary to override the project
> version. The custom version may not be compatible with how Version works, or
> the user may want to add extra metadata (like a build number). We can add a
> property which defaults to ${project.version} but allows the user to specify
> separately if desired.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: Handling of fixVersion for umbrella tasks
Thank you both for the input. That's a good idea Andrew, I'll take a stab at it. I have a script (based on Nick's git-jira-release-audit [1]) which I'm using to audit versions. I'll see if I can add this to that so we can automate that cleanup for future .0 releases. [1] https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit On Sun, Jan 14, 2024 at 8:50 PM Andrew Purtell wrote: > For 2.5.0 I based the change log on the change log of what was then the > last/most recent 2.4 release. Anything committed into 2.4 with a fix > version of 2.5, I dropped the 2.5 fix version. The 2.5 fix version was kept > for anything novel in 2.5. The result was an orderly cumulative change log. > I also audited the commit history to make sure no change was committed to > 2.4 and not 2.5. This took quite a bit of time. I do not think it can be > avoided but needs be done only for the .0 release. > > > > On Jan 14, 2024, at 2:37 AM, 张铎 wrote: > > > > Usually we will only set fix version if there is a commit. > > > > The only exception is for some umbrella issues where we want to put a > > fat release note there, such as HBASE-26067. > > > > This will introduce some difficulties to the RMs as it will cause > > mismatches on the commit history and CHANGES.md. But anyway, you need > > to manually check the issue if it is missed in the commit history, if > > it is an umbrella issue like HBASE-26067, you can just ignore it. > > > > Thanks. > > > > Bryan Beaudreault 于2024年1月14日周日 09:27写道： > >> > >> Hi Devs, > >> > >> I'm working on auditing the 2.6.0 fixVersion JIRAs in prep for the RC0. > One > >> thing I'm noticing is there are a couple umbrella JIRAs which have > >> fixVersion of 2.6.0 but no corresponding commit in the branch. This is > >> because all of the work was done in sub-tasks, and those sub-tasks are > in > >> the branch. Here's an example: > >> https://issues.apache.org/jira/browse/HBASE-26067 > >> > >> I'm curious how we want to handle this. On the one hand it seems good > to be > >> able to 1-to-1 link JIRA fixVersion to commits in branches. On the other > >> hand, umbrella are useful aggregators and can be nice for consolidating > >> release notes. > >> > >> Maybe the audit tool I'm working with can just ignore umbrella, or maybe > >> umbrella tasks should be handled in a feature branch and eventually > merged > >> in with the umbrella jira ID. > >> > >> Thoughts? >
[jira] [Created] (HBASE-28316) Add BootstrapNodeService handlers
Bryan Beaudreault created HBASE-28316: - Summary: Add BootstrapNodeService handlers Key: HBASE-28316 URL: https://issues.apache.org/jira/browse/HBASE-28316 Project: HBase Issue Type: Sub-task Affects Versions: 3.0.0-beta-1, 2.6.0 Reporter: Bryan Beaudreault We added calls to a BootstrapNodeService, but the servers are not setup to serve it. We need to add in two places: * RSRPCServices list of services: [https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L1447] * HBasePolicyProvider mapping of acl to service: [https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/security/HBasePolicyProvider.java#L40] Without adding to these two places, you first see UnknownServiceExceptions and then you see AccessDeniedExceptions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28315) Remove noisy WARN from trying to construct MetricsServlet
Bryan Beaudreault created HBASE-28315: - Summary: Remove noisy WARN from trying to construct MetricsServlet Key: HBASE-28315 URL: https://issues.apache.org/jira/browse/HBASE-28315 Project: HBase Issue Type: Improvement Affects Versions: 3.0.0-beta-1, 2.6.0 Reporter: Bryan Beaudreault MetricsServlet is deprecated since hadoop 2.8 and removed in hadoop3. In HBASE-20904 the servlet initialization was refactored, and we now have a noisy WARN (with stacktrace) when MetricsServlet does not exist. This should be common, since hadoop3 is the modern version to run on (hadoop2 almost EOL). We shouldn't warn. Fix the code to not produce a warn when MetricsServlet is not available. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (HBASE-28256) Enhance ByteBufferUtils.readVLong to read more bytes at a time
[ https://issues.apache.org/jira/browse/HBASE-28256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Beaudreault resolved HBASE-28256. --- Fix Version/s: 2.6.0 2.5.8 3.0.0-beta-2 Resolution: Fixed Pushed to all active release branches. Thanks for the great work here [~bewing], and for the review [~zhangduo]. > Enhance ByteBufferUtils.readVLong to read more bytes at a time > -- > > Key: HBASE-28256 > URL: https://issues.apache.org/jira/browse/HBASE-28256 > Project: HBase > Issue Type: Improvement > Components: Performance >Reporter: Becker Ewing >Assignee: Becker Ewing >Priority: Major > Fix For: 2.6.0, 2.5.8, 3.0.0-beta-2 > > Attachments: ReadVLongBenchmark.zip, async-prof-rs-cpu.html > > > Currently, ByteBufferUtils.readVLong is used to decode rows in all data block > encodings in order to read the memstoreTs field. For a data block encoding > like prefix, ByteBufferUtils.readVLong can surprisingly occupy over 50% of > the CPU time in BufferedEncodedSeeker.decodeNext (which can be quite a hot > method in seek operations). > > Since memstoreTs will typically require at least 6 bytes to store, we could > look to vectorize the read path for readVLong to read 8 bytes at a time > instead of a single byte at a time (like in > https://issues.apache.org/jira/browse/HBASE-28025) in order to increase > performance. > > Attached is a CPU flamegraph of a region server process which shows that we > spend a surprising amount of time in decoding rows from the DBE in > ByteBufferUtils.readVLong. -- This message was sent by Atlassian Jira (v8.20.10#820010)
