[jira] [Resolved] (HBASE-26709) Ban the usage of junit 3 TestCase
[ https://issues.apache.org/jira/browse/HBASE-26709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-26709. --- Fix Version/s: 3.0.0-alpha-3 Hadoop Flags: Reviewed Resolution: Fixed Only merged to master. Since on branch-2, we will have HBaseTestCase whch is junit 3 based. > Ban the usage of junit 3 TestCase > - > > Key: HBASE-26709 > URL: https://issues.apache.org/jira/browse/HBASE-26709 > Project: HBase > Issue Type: Improvement > Components: test >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0-alpha-3 > > > We should move up all our UTs to junit 4 style. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (HBASE-26690) Modify FSTableDescriptors to not rely on renaming when writing TableDescriptor
[ https://issues.apache.org/jira/browse/HBASE-26690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-26690. --- Fix Version/s: 2.6.0 3.0.0-alpha-3 Hadoop Flags: Reviewed Resolution: Fixed Pushed to master and branch-2. Thanks [~wchevreuil] for reviewing. > Modify FSTableDescriptors to not rely on renaming when writing TableDescriptor > -- > > Key: HBASE-26690 > URL: https://issues.apache.org/jira/browse/HBASE-26690 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.6.0, 3.0.0-alpha-3 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (HBASE-26714) Introduce path configuration for system coprocessors
Tak-Lon (Stephen) Wu created HBASE-26714:
Summary: Introduce path configuration for system coprocessors
Key: HBASE-26714
URL: https://issues.apache.org/jira/browse/HBASE-26714
Project: HBase
Issue Type: Task
Components: Coprocessors
Affects Versions: 2.5.0, 3.0.0-alpha-3
Reporter: Tak-Lon (Stephen) Wu
Currently when region server starts, system coprocessors are normally loaded as
part of the local classpath and the jar is stored in the local storage; in
short words, Operator would have to copy the jar to each host (or a shared file
system) and construct it as part of HBASE_CLASSPATH.
although operator may have been doing the presetup of copying jar and making it
available to the HBASE_CLASSPATH without any issue, it could be helpful if we
provide an alternative method and centralize this configuration in hbase-site
similar to the support of table-level coprocessor, e.g. configuring
{{hbase.coprocessor.region.classes}} with the local/remote path along with the
classname with a specific path token in the form of {{className|priority|path}}.
Similarly in HBASE-23710, it provided the priority configuration via hbase-site
that this new improvement aligns with the same purpose, and further help to
simplify the deployment of System Coprocessors to e.g. hdfs or supported cloud
storage.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (HBASE-26713) Increments submitted by 1.x clients will be stored with timestamp 0 on 2.x+ clusters
Bryan Beaudreault created HBASE-26713: - Summary: Increments submitted by 1.x clients will be stored with timestamp 0 on 2.x+ clusters Key: HBASE-26713 URL: https://issues.apache.org/jira/browse/HBASE-26713 Project: HBase Issue Type: Bug Reporter: Bryan Beaudreault We discovered this in our work on upgrading from ~1.2.0 to 2.4.6. A 1.2.0 client will submit an Increment, without specifying a timestamp. This should be translated as LATEST_TIMESTAMP, but an hbase 2 server will store it with a timestamp of 0. This is because the QualifierValue timestamp proto field is optional, and is not set in branch-1 MutationProtos: [https://github.com/apache/hbase/blob/branch-1/hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/RequestConverter.java#L218-L219.] In branch-1, the timestamp is actually ignored entirely: [https://github.com/apache/hbase/blob/branch-1/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java#L8435-L8456.] So this is not an issue there. As of HBASE-18546, the timestamp is no longer ignored, but the usage of QualiferValue.getTimestamp() in deserialization is not wrapped in a .hasTimestamp() call: [https://github.com/apache/hbase/blob/7d8dc3524981a04e82ff236bb3dc18d36ebc82b4/hbase-client/src/main/java/org/apache/hadoop/hbase/shaded/protobuf/ProtobufUtil.java#L886-L909]. The default value for non-present optionals is defined by the underlying primitive, so for longs that is 0. Since the Increment's timestamp is now respected by HRegion, it causes the erroneous 0 value to be stored: [https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java#L4180] (updateLatestStamp only overwrites the cell timestamp if it's LATEST_TIMESTAMP, which in this case it has been deserialized as 0) I think this might only apply to clients who do not use a KeyValueCodec. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (HBASE-26712) Balancer encounters NPE in rare case
Viraj Jasani created HBASE-26712:
Summary: Balancer encounters NPE in rare case
Key: HBASE-26712
URL: https://issues.apache.org/jira/browse/HBASE-26712
Project: HBase
Issue Type: Bug
Affects Versions: 2.4.9
Reporter: Viraj Jasani
{code:java}
ERROR [ster-1:6.Chore.1] hbase.ScheduledChore - Caught error
java.lang.NullPointerException
at
org.apache.hadoop.hbase.master.assignment.AssignmentManager.balance(AssignmentManager.java:758)
at
org.apache.hadoop.hbase.master.HMaster.executeRegionPlansWithThrottling(HMaster.java:1834)
at org.apache.hadoop.hbase.master.HMaster.balance(HMaster.java:1797)
at org.apache.hadoop.hbase.master.HMaster.balance(HMaster.java:1707)
at
org.apache.hadoop.hbase.master.balancer.BalancerChore.chore(BalancerChore.java:49)
at org.apache.hadoop.hbase.ScheduledChore.run(ScheduledChore.java:153)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at
org.apache.hadoop.hbase.JitterScheduledThreadPoolExecutorImpl$JitteredRunnableScheduledFuture.run(JitterScheduledThreadPoolExecutorImpl.java:111)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
Let's fix this.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (HBASE-26711) Remove 2.3 from Download page
Peter Somogyi created HBASE-26711: - Summary: Remove 2.3 from Download page Key: HBASE-26711 URL: https://issues.apache.org/jira/browse/HBASE-26711 Project: HBase Issue Type: Sub-task Reporter: Peter Somogyi Assignee: Peter Somogyi -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (HBASE-26710) Remove jenkins files from branch-2.3
Peter Somogyi created HBASE-26710: - Summary: Remove jenkins files from branch-2.3 Key: HBASE-26710 URL: https://issues.apache.org/jira/browse/HBASE-26710 Project: HBase Issue Type: Sub-task Components: community Reporter: Peter Somogyi Assignee: Peter Somogyi Remove jenkins files as 2.3 reached EOL. -- This message was sent by Atlassian Jira (v8.20.1#820001)
