[jira] [Resolved] (HBASE-21674) Port HBASE-21652 (Refactor ThriftServer making thrift2 server inherited from thrift1 server) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-21674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reid Chan resolved HBASE-21674. --- Hadoop Flags: Reviewed Resolution: Resolved > Port HBASE-21652 (Refactor ThriftServer making thrift2 server inherited from > thrift1 server) to branch-1 > > > Key: HBASE-21674 > URL: https://issues.apache.org/jira/browse/HBASE-21674 > Project: HBase > Issue Type: Sub-task > Components: Thrift >Reporter: Andrew Kyle Purtell >Assignee: Yutong Xiao >Priority: Major > Fix For: 1.7.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: HBase
What's your jira user id? I can help you added to the contributor list and then you'll be able to assign jiras. On Tue, Jun 22, 2021 at 10:37 AM 曹明 <13760436...@163.com> wrote: > How can I assign the issue to me?
HBase
How can I assign the issue to me?
[jira] [Created] (HBASE-26021) HBase 1.7 to 2.4 upgrade issue
Viraj Jasani created HBASE-26021:
Summary: HBase 1.7 to 2.4 upgrade issue
Key: HBASE-26021
URL: https://issues.apache.org/jira/browse/HBASE-26021
Project: HBase
Issue Type: Bug
Affects Versions: 2.4.4, 1.7.0
Reporter: Viraj Jasani
As of today, if we bring up HBase cluster using branch-1 and upgrade to
branch-2.4, we are facing issue while parsing namespace from HDFS fileinfo.
Instead of "*hbase:meta*" and "*hbase:namespace*", parsing using ProtobufUtil
seems to be producing "*\n hbase:\n meta*" and "*\n hbase:\n namespace*"
{code:java}
2021-06-22 00:05:56,611 INFO
[RpcServer.priority.RWQ.Fifo.read.handler=3,queue=1,port=16025]
regionserver.RSRpcServices: Open hbase:meta,,1.1588230740
2021-06-22 00:05:56,648 INFO
[RpcServer.priority.RWQ.Fifo.read.handler=5,queue=1,port=16025]
regionserver.RSRpcServices: Open
hbase:namespace,,1624297762817.396cb6cc00cd4334cb1ea3a792d7529a.
2021-06-22 00:05:56,759 ERROR
[RpcServer.priority.RWQ.Fifo.read.handler=5,queue=1,port=16025] ipc.RpcServer:
Unexpected throwable object
java.lang.IllegalArgumentException: Illegal character <
> at 0. Namespaces may only contain 'alphanumeric characters' from any language
> and digits:
^Ehbase^R namespace
at
org.apache.hadoop.hbase.TableName.isLegalNamespaceName(TableName.java:246)
at
org.apache.hadoop.hbase.TableName.isLegalNamespaceName(TableName.java:220)
at org.apache.hadoop.hbase.TableName.(TableName.java:348)
at
org.apache.hadoop.hbase.TableName.createTableNameIfNecessary(TableName.java:385)
at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:508)
at
org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.toTableName(ProtobufUtil.java:2292)
at
org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.toTableDescriptor(ProtobufUtil.java:2937)
at
org.apache.hadoop.hbase.client.TableDescriptorBuilder$ModifyableTableDescriptor.parseFrom(TableDescriptorBuilder.java:1625)
at
org.apache.hadoop.hbase.client.TableDescriptorBuilder$ModifyableTableDescriptor.access$200(TableDescriptorBuilder.java:597)
at
org.apache.hadoop.hbase.client.TableDescriptorBuilder.parseFrom(TableDescriptorBuilder.java:320)
at
org.apache.hadoop.hbase.util.FSTableDescriptors.readTableDescriptor(FSTableDescriptors.java:511)
at
org.apache.hadoop.hbase.util.FSTableDescriptors.getTableDescriptorFromFs(FSTableDescriptors.java:496)
at
org.apache.hadoop.hbase.util.FSTableDescriptors.getTableDescriptorFromFs(FSTableDescriptors.java:482)
at
org.apache.hadoop.hbase.util.FSTableDescriptors.get(FSTableDescriptors.java:210)
at
org.apache.hadoop.hbase.regionserver.RSRpcServices.openRegion(RSRpcServices.java:2112)
at
org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:35218)
at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:395)
at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
at
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:338)
at
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:318)
2021-06-22 00:05:56,759 ERROR
[RpcServer.priority.RWQ.Fifo.read.handler=3,queue=1,port=16025] ipc.RpcServer:
Unexpected throwable object
java.lang.IllegalArgumentException: Illegal character <
> at 0. Namespaces may only contain 'alphanumeric characters' from any language
> and digits:
^Ehbase^R^Dmeta
at
org.apache.hadoop.hbase.TableName.isLegalNamespaceName(TableName.java:246)
at
org.apache.hadoop.hbase.TableName.isLegalNamespaceName(TableName.java:220)
at org.apache.hadoop.hbase.TableName.(TableName.java:348)
at
org.apache.hadoop.hbase.TableName.createTableNameIfNecessary(TableName.java:385)
at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:508)
at
org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.toTableName(ProtobufUtil.java:2292)
at
org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.toTableDescriptor(ProtobufUtil.java:2937)
at
org.apache.hadoop.hbase.client.TableDescriptorBuilder$ModifyableTableDescriptor.parseFrom(TableDescriptorBuilder.java:1625)
at
org.apache.hadoop.hbase.client.TableDescriptorBuilder$ModifyableTableDescriptor.access$200(TableDescriptorBuilder.java:597)
at
org.apache.hadoop.hbase.client.TableDescriptorBuilder.parseFrom(TableDescriptorBuilder.java:320)
at
org.apache.hadoop.hbase.util.FSTableDescriptors.readTableDescriptor(FSTableDescriptors.java:511)
at
org.apache.hadoop.hbase.util.FSTableDescriptors.getTableDescriptorFromFs(FSTableDescriptors.java:496)
at
org.apache.hadoop.hbase.util.FSTableDescriptors.getTableDescriptorFromFs(FSTableDescriptors.java:482)
at
org.apache.hadoop.hbase.util.FSTable
[jira] [Resolved] (HBASE-25992) Polish the ReplicationSourceWALReader code for 2.x after HBASE-25596
[ https://issues.apache.org/jira/browse/HBASE-25992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-25992. --- Resolution: Fixed Pushed an addendum to add the 'catch WALEntryFilterRetryableException' back. > Polish the ReplicationSourceWALReader code for 2.x after HBASE-25596 > > > Key: HBASE-25992 > URL: https://issues.apache.org/jira/browse/HBASE-25992 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.5 > > > The code are very different for 2.x and 1.x, and the original code for > HBASE-25596 is for 1.x, so create this issue to polish the code to make it > more suitable for 2.x. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (HBASE-25992) Polish the ReplicationSourceWALReader code for 2.x after HBASE-25596
[ https://issues.apache.org/jira/browse/HBASE-25992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang reopened HBASE-25992: --- This breaks TestWALEntryStream.testReplicationSourceWALReaderWithFailingFilter. > Polish the ReplicationSourceWALReader code for 2.x after HBASE-25596 > > > Key: HBASE-25992 > URL: https://issues.apache.org/jira/browse/HBASE-25992 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.5 > > > The code are very different for 2.x and 1.x, and the original code for > HBASE-25596 is for 1.x, so create this issue to polish the code to make it > more suitable for 2.x. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-26020) Split TestWALEntryStream.testDifferentCounts out
Duo Zhang created HBASE-26020: - Summary: Split TestWALEntryStream.testDifferentCounts out Key: HBASE-26020 URL: https://issues.apache.org/jira/browse/HBASE-26020 Project: HBase Issue Type: Improvement Components: Replication, test Reporter: Duo Zhang Assignee: Duo Zhang It consumes too much time and may cause the whole UT to timeout. And in fact, it should be implemented as parameterized. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-26019) Remove reflections used in HBaseConfiguration.getPassword()
Wei-Chiu Chuang created HBASE-26019: --- Summary: Remove reflections used in HBaseConfiguration.getPassword() Key: HBASE-26019 URL: https://issues.apache.org/jira/browse/HBASE-26019 Project: HBase Issue Type: Improvement Reporter: Wei-Chiu Chuang HBaseConfiguration.getPassword() uses Hadoop API Configuration.getPassword(). The API was added in Hadoop 2.6.0. Reflection was used to access the API. It's time to remove the reflection and invoke the API directly. (HBase 3.0 as well as 2.x too) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-26018) Perf improvement in L1 cache
Viraj Jasani created HBASE-26018: Summary: Perf improvement in L1 cache Key: HBASE-26018 URL: https://issues.apache.org/jira/browse/HBASE-26018 Project: HBase Issue Type: Improvement Affects Versions: 2.4.4, 2.3.5, 3.0.0-alpha-1 Reporter: Viraj Jasani Assignee: Viraj Jasani Fix For: 3.0.0-alpha-1, 2.5.0, 2.3.6, 2.4.5 After HBASE-25698 is in, all L1 caching strategies perform buffer.retain() in order to maintain refCount atomically while retrieving cached blocks (CHM#computeIfPresent). Retaining refCount is coming up bit expensive in terms of performance issues. Using computeIfPresent API, CHM uses coarse grained segment locking and even if our computation is not so complex (we just call block retain API), it will block other update APIs for the key. computeIfPresent keeps showing up on flame graphs as well (attached one of them). Specifically when we see aggressive cache hits for meta blocks (with major blocks in cache), we would want to get away from coarse grained locking. One of the suggestions came up while reviewing PR#3215 is to treat cache read API as optimistic read and deal with block retain based refCount issues by catching the respective Exception and let it treat as cache miss. This should allow us to go ahead with lockless get API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-26001) When turn on access control, the cell level TTL of Increment and Append operations is invalid.
[
https://issues.apache.org/jira/browse/HBASE-26001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reid Chan resolved HBASE-26001.
---
Hadoop Flags: Reviewed
Resolution: Fixed
> When turn on access control, the cell level TTL of Increment and Append
> operations is invalid.
> --
>
> Key: HBASE-26001
> URL: https://issues.apache.org/jira/browse/HBASE-26001
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Yutong Xiao
>Assignee: Yutong Xiao
>Priority: Minor
> Fix For: 3.0.0-alpha-1, 2.6.7, 2.5.0, 2.3.6, 2.4.5
>
>
> AccessController postIncrementBeforeWAL() and postAppendBeforeWAL() methods
> will rewrite the new cell's tags by the old cell's. This will makes the other
> kinds of tag in new cell invisible (such as TTL tag) after this. As in
> Increment and Append operations, the new cell has already catch forward all
> tags of the old cell and TTL tag from mutation operation, here in
> AccessController we do not need to rewrite the tags once again. Also, the TTL
> tag of newCell will be invisible in the new created cell. Actually, in
> Increment and Append operations, the newCell has already copied all tags of
> the oldCell. So the oldCell is useless here.
> {code:java}
> private Cell createNewCellWithTags(Mutation mutation, Cell oldCell, Cell
> newCell) {
> // Collect any ACLs from the old cell
> List tags = Lists.newArrayList();
> List aclTags = Lists.newArrayList();
> ListMultimap perms = ArrayListMultimap.create();
> if (oldCell != null) {
> Iterator tagIterator = PrivateCellUtil.tagsIterator(oldCell);
> while (tagIterator.hasNext()) {
> Tag tag = tagIterator.next();
> if (tag.getType() != PermissionStorage.ACL_TAG_TYPE) {
> // Not an ACL tag, just carry it through
> if (LOG.isTraceEnabled()) {
> LOG.trace("Carrying forward tag from " + oldCell + ": type " +
> tag.getType()
> + " length " + tag.getValueLength());
> }
> tags.add(tag);
> } else {
> aclTags.add(tag);
> }
> }
> }
> // Do we have an ACL on the operation?
> byte[] aclBytes = mutation.getACL();
> if (aclBytes != null) {
> // Yes, use it
> tags.add(new ArrayBackedTag(PermissionStorage.ACL_TAG_TYPE, aclBytes));
> } else {
> // No, use what we carried forward
> if (perms != null) {
> // TODO: If we collected ACLs from more than one tag we may have a
> // List of size > 1, this can be collapsed into a single
> // Permission
> if (LOG.isTraceEnabled()) {
> LOG.trace("Carrying forward ACLs from " + oldCell + ": " + perms);
> }
> tags.addAll(aclTags);
> }
> }
> // If we have no tags to add, just return
> if (tags.isEmpty()) {
> return newCell;
> }
> // Here the new cell's tags will be in visible.
> return PrivateCellUtil.createCell(newCell, tags);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (HBASE-26004) Port HBASE-26001 (cell level tags invisible in atomic operations when access control is on) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-26004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reid Chan resolved HBASE-26004. --- Hadoop Flags: Reviewed Resolution: Fixed > Port HBASE-26001 (cell level tags invisible in atomic operations when access > control is on) to branch-1 > --- > > Key: HBASE-26004 > URL: https://issues.apache.org/jira/browse/HBASE-26004 > Project: HBase > Issue Type: Bug >Reporter: Yutong Xiao >Assignee: Yutong Xiao >Priority: Minor > Fix For: 1.7.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
