[jira] [Created] (HBASE-21774) do not use currentMillis to measure intervals
Sergey Shelukhin created HBASE-21774: Summary: do not use currentMillis to measure intervals Key: HBASE-21774 URL: https://issues.apache.org/jira/browse/HBASE-21774 Project: HBase Issue Type: Bug Reporter: Sergey Shelukhin I've noticed it in a few places in the code... currentMillis can go backwards and have other artifacts. nanoTime should be used for intervals unless it's both the case that the calls are frequent and nanoTime will result in perf overhead, and also that artifacts from negative intervals and such are relatively harmless or possible to work around in the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[NOTICE] Hadoop project discussing EOL for Hadoop 2.7
heads up that the Apache Hadoop project is discussing marking their 2.7 release line as EOL: https://s.apache.org/Nm83 Hadoop 2.7.1+ is the most recent Hadoop release line to get the "(y)" marker in our Hadoop matrix for HBase branches-1. It's also the earliest Hadoop release line to get the same for our HBase branches-2. If folks want to weigh in on that discussion, now's the time. What, if anything, do we as a community want to do to prepare for when it eventually happens?
[jira] [Created] (HBASE-21775) The BufferedMutator doesn't ever refresh region location cache
Tommy Li created HBASE-21775:
Summary: The BufferedMutator doesn't ever refresh region location
cache
Key: HBASE-21775
URL: https://issues.apache.org/jira/browse/HBASE-21775
Project: HBase
Issue Type: Bug
Components: Client
Reporter: Tommy Li
Assignee: Tommy Li
Fix For: 3.0.0
{color:#22}I noticed in some of my writing jobs that the BufferedMutator
would get stuck retrying writes against a dead server.{color}
{code:java}
19/01/18 15:15:47 INFO [Executor task launch worker for task 0]
client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
dummy_table
19/01/18 15:15:54 WARN [htable-pool3-t56] client.AsyncRequestFutureImpl: id=2,
table=dummy_table, attempt=15/21, failureCount=1ops, last
exception=org.apache.hadoop.hbase.DoNotRetryIOException: Operation rpcTimeout
on ,17020,1547848193782, tracking started Fri Jan 18 14:55:37 PST 2019;
NOT retrying, failed=1 -- final attempt!
19/01/18 15:15:54 ERROR [Executor task launch worker for task 0]
IngestRawData.map(): [B@258bc2c7:
org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1
action: Operation rpcTimeout: 1 time, servers with issues:
,17020,1547848193782
{code}
After the single remaining action permanently failed, it would resume progress
only to get stuck again retrying against the same dead server:
{code:java}
19/01/18 15:21:18 INFO [Executor task launch worker for task 0]
client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
dummy_table
19/01/18 15:21:18 INFO [Executor task launch worker for task 0]
client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
dummy_table
19/01/18 15:21:20 INFO [htable-pool3-t55] client.AsyncRequestFutureImpl: id=2,
table=dummy_table, attempt=6/21, failureCount=1ops, last
exception=java.net.ConnectException: Call to failed on connection
exception:
org.apache.hbase.thirdparty.io.netty.channel.ConnectTimeoutException:
connection timed out: on ,17020,1547848193782, tracking
started null, retrying after=20089ms, operationsToReplay=1
{code}
Only restarting the client process to generate a new BufferedMutator instance
would fix the issue, at least until the next regionserver crash
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21773) rowcounter utility should respond to please for help
Sean Busbey created HBASE-21773:
---
Summary: rowcounter utility should respond to please for help
Key: HBASE-21773
URL: https://issues.apache.org/jira/browse/HBASE-21773
Project: HBase
Issue Type: Bug
Components: tooling
Affects Versions: 2.1.0
Reporter: Sean Busbey
{{hbase rowcounter}} does not respond to reasonable requests for help, i.e.
{{--help}}, {{-h}}, or {{-?}}
{code}
[systest@busbey-training-1 root]$ hbase rowcounter -?
OpenJDK 64-Bit Server VM warning: Using incremental CMS is deprecated and will
likely be removed in a future release
19/01/24 12:30:00 INFO client.RMProxy: Connecting to ResourceManager at
busbey-training-1.gce.cloudera.com/172.31.116.31:8032
19/01/24 12:30:01 INFO hdfs.DFSClient: Created token for systest:
HDFS_DELEGATION_TOKEN owner=syst...@gce.cloudera.com, renewer=yarn, realUser=,
issueDate=1548361801519, maxDate=1548966601519, sequenceNumber=3, masterKeyId=8
on 172.31.116.31:8020
19/01/24 12:30:01 INFO kms.KMSClientProvider: Getting new token from
https://busbey-training-3.gce.cloudera.com:16000/kms/v1/,
renewer:yarn/busbey-training-1.gce.cloudera@gce.cloudera.com
19/01/24 12:30:02 INFO kms.KMSClientProvider: New token received: (Kind:
kms-dt, Service: 172.31.116.52:16000, Ident: (kms-dt owner=systest,
renewer=yarn, realUser=, issueDate=1548361801965, maxDate=1548966601965,
sequenceNumber=5, masterKeyId=17))
19/01/24 12:30:02 INFO security.TokenCache: Got dt for
hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: HDFS_DELEGATION_TOKEN,
Service: 172.31.116.31:8020, Ident: (token for systest: HDFS_DELEGATION_TOKEN
owner=syst...@gce.cloudera.com, renewer=yarn, realUser=,
issueDate=1548361801519, maxDate=1548966601519, sequenceNumber=3, masterKeyId=8)
19/01/24 12:30:02 INFO security.TokenCache: Got dt for
hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: kms-dt, Service:
172.31.116.52:16000, Ident: (kms-dt owner=systest, renewer=yarn, realUser=,
issueDate=1548361801965, maxDate=1548966601965, sequenceNumber=5,
masterKeyId=17)
19/01/24 12:30:02 INFO kms.KMSClientProvider: Getting new token from
https://busbey-training-4.gce.cloudera.com:16000/kms/v1/,
renewer:yarn/busbey-training-1.gce.cloudera@gce.cloudera.com
19/01/24 12:30:02 INFO kms.KMSClientProvider: New token received: (Kind:
kms-dt, Service: 172.31.116.50:16000, Ident: (kms-dt owner=systest,
renewer=yarn, realUser=, issueDate=1548361802363, maxDate=1548966602363,
sequenceNumber=6, masterKeyId=18))
19/01/24 12:30:02 INFO security.TokenCache: Got dt for
hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: kms-dt, Service:
172.31.116.50:16000, Ident: (kms-dt owner=systest, renewer=yarn, realUser=,
issueDate=1548361802363, maxDate=1548966602363, sequenceNumber=6,
masterKeyId=18)
19/01/24 12:30:02 INFO mapreduce.JobResourceUploader: Disabling Erasure Coding
for path: /user/systest/.staging/job_1548349234632_0003
19/01/24 12:30:03 INFO mapreduce.JobSubmitter: Cleaning up the staging area
/user/systest/.staging/job_1548349234632_0003
Exception in thread "main" java.lang.IllegalArgumentException: Illegal first
character <45> at 0. User-space table qualifiers can only start with
'alphanumeric characters' from any language: -?
at
org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:193)
at
org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:156)
at org.apache.hadoop.hbase.TableName.(TableName.java:346)
at
org.apache.hadoop.hbase.TableName.createTableNameIfNecessary(TableName.java:382)
at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:469)
at
org.apache.hadoop.hbase.mapreduce.TableInputFormat.initialize(TableInputFormat.java:198)
at
org.apache.hadoop.hbase.mapreduce.TableInputFormatBase.getSplits(TableInputFormatBase.java:243)
at
org.apache.hadoop.hbase.mapreduce.TableInputFormat.getSplits(TableInputFormat.java:254)
at
org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:310)
at
org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:327)
at
org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:200)
at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1570)
at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1567)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1875)
at org.apache.hadoop.mapreduce.Job.submit(Job.java:1567)
at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1588)
at org.apache.hadoop.hbase.mapreduce.RowCounter.run(RowCounter.java:242)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76)
at
[jira] [Created] (HBASE-21778) Remove the usage of the locateRegion related methods in ClusterConnection
Duo Zhang created HBASE-21778: - Summary: Remove the usage of the locateRegion related methods in ClusterConnection Key: HBASE-21778 URL: https://issues.apache.org/jira/browse/HBASE-21778 Project: HBase Issue Type: Sub-task Reporter: Duo Zhang As now RegionLocator can give you everything. So later we could remove the ClusterConnection completely. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [NOTICE] Hadoop project discussing EOL for Hadoop 2.7
We could see what 2.9.2 looks like in terms of suitability and stability. Is there any reason to look at 2.8 instead of jumping directly to 2.9? On Thu, Jan 24, 2019 at 1:33 PM Sean Busbey wrote: > heads up that the Apache Hadoop project is discussing marking their 2.7 > release line as EOL: > > https://s.apache.org/Nm83 > > Hadoop 2.7.1+ is the most recent Hadoop release line to get the "(y)" > marker in our Hadoop matrix for HBase branches-1. It's also the earliest > Hadoop release line to get the same for our HBase branches-2. > > If folks want to weigh in on that discussion, now's the time. What, if > anything, do we as a community want to do to prepare for when it eventually > happens? > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
[jira] [Created] (HBASE-21781) list_deadservers elapsed time is incorrect
xuqinya created HBASE-21781:
---
Summary: list_deadservers elapsed time is incorrect
Key: HBASE-21781
URL: https://issues.apache.org/jira/browse/HBASE-21781
Project: HBase
Issue Type: Bug
Components: shell
Affects Versions: 1.4.9
Reporter: xuqinya
Assignee: xuqinya
list_deadservers elapsed time is incorrect.As follows,
{code:java}
hbase(main):006:0> list_deadservers
SERVERNAME
0 row(s) in 1548384431.9810 seconds
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21780) Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
Sakthi created HBASE-21780: -- Summary: Avoid a wide line on the RegionServer webUI for many ZooKeeper servers Key: HBASE-21780 URL: https://issues.apache.org/jira/browse/HBASE-21780 Project: HBase Issue Type: Improvement Reporter: Sakthi Assignee: Sakthi HBASE-8812 made this change for MasterUI but not for RegionServer UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21777) "Tune compaction throughput" debug messages even when nothing has changed
Andrew Purtell created HBASE-21777: -- Summary: "Tune compaction throughput" debug messages even when nothing has changed Key: HBASE-21777 URL: https://issues.apache.org/jira/browse/HBASE-21777 Project: HBase Issue Type: Bug Affects Versions: 1.5.0 Reporter: Andrew Purtell Assignee: Andrew Purtell Fix For: 1.5.0 PressureAwareCompactionThroughputController will log "tune compaction throughput" debug messages even when after consideration the re-tuning makes no change to current settings. In that case it would be better not to log anything. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21776) Duplicate "Set storagePolicy" debug logging
Andrew Purtell created HBASE-21776: -- Summary: Duplicate "Set storagePolicy" debug logging Key: HBASE-21776 URL: https://issues.apache.org/jira/browse/HBASE-21776 Project: HBase Issue Type: Bug Affects Versions: 1.5.0 Reporter: Andrew Purtell Assignee: Andrew Purtell Fix For: 1.5.0 An example: 2019-01-25 02:57:15,831 DEBUG [regionserver/ip-172-31-13-83.us-west-2.compute.internal/172.31.13.83:8120-longCompactions-1548384634805] util.CommonFSUtils: Set storagePolicy=HOT for path=hdfs://ip-172-31-5-95.us-west-2.compute.internal:8020/hbase/data/default/IntegrationTestBigLinkedList/16899cdfdb4ab217208f4108ad0c4803/.tmp/meta 2019-01-25 02:57:15,831 DEBUG [regionserver/ip-172-31-13-83.us-west-2.compute.internal/172.31.13.83:8120-longCompactions-1548384634805] util.CommonFSUtils: Set storagePolicy=HOT for path=hdfs://ip-172-31-5-95.us-west-2.compute.internal:8020/hbase/data/default/IntegrationTestBigLinkedList/16899cdfdb4ab217208f4108ad0c4803/.tmp/meta Seen most often during compactions. Ideally we only log once per directory per flush or compaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21779) Reimplement SecureBulkLoadClient to use AsyncClusterConnection
Duo Zhang created HBASE-21779: - Summary: Reimplement SecureBulkLoadClient to use AsyncClusterConnection Key: HBASE-21779 URL: https://issues.apache.org/jira/browse/HBASE-21779 Project: HBase Issue Type: Sub-task Reporter: Duo Zhang So we will not rely on the RpcRetryingCaller and ServiceCallable any more. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-21603) Move access control service from regionserver to master
[ https://issues.apache.org/jira/browse/HBASE-21603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Mei resolved HBASE-21603. Resolution: Won't Fix Split the task into several tasks, see HBASE-21739. > Move access control service from regionserver to master > --- > > Key: HBASE-21603 > URL: https://issues.apache.org/jira/browse/HBASE-21603 > Project: HBase > Issue Type: Sub-task >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > > Create a sub task to move access control service from regionserver to master. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21782) LoadIncrementalHFiles should not be IA.Public
Duo Zhang created HBASE-21782: - Summary: LoadIncrementalHFiles should not be IA.Public Key: HBASE-21782 URL: https://issues.apache.org/jira/browse/HBASE-21782 Project: HBase Issue Type: Task Reporter: Duo Zhang It is an implementation class, so some of the methods which are only supposed to be used by replication sink are also public to users. And it exposes methods which take Table and Connection as parameter and inside the implementation we assume that they are HTable and ConnectionImplementation, which will be a pain when we want to replace the sync client implementation with async client. Here I think we should make the implementation class as IA.LimitPrivate(TOOL), and introduce an interface for bulking hfiles programmatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
About the performance of In-Memory Compaction.
Hi
Recently, I made some performance tests for evaluating DefaultMemstore and
CompactintMemstore.
*Performance when using the DefaultMemstore.*
[image: image.png]
*Performance when using the CompactingMemstore.*
[image: image.png]
We can see that the latency control of CompactingMemstore (especially the
p999) is awesome.
P999 < 50ms when enable in-memory compaction, while 50ms < p999 < 100ms
when using the
default memstore. Besides, other metrics such as qps/p99/avg are amost the
same. *Obviously,*
*the CompactingMemstore performs better in our test, compared to
DefaultMemstore. *
So my question is: In HBASE-20188, we've discussed whether setting the
CompactingMemstore
as the default memstore, while we didn't do that. Is there any other deeper
consideration ?
Read performance degradation after enable IMC ? stability consideration ?
Slower memstore
flush compared to branch-1 ?
(Actually, I read the comments in HBASE-20188 serveral times, and found the
context is quite
complex, and did got the points, so create this thread)
*BTW, my test env are following:*
5 Nodes : 12*800G SSD / 24 Core / 128GB memory
(50G onheap + 50G offheap for each RS, and allocated 36G for BucketCache,
used asyncfswal).
The offheap 50G was not be used in my 100% put test (maybe parts of them
used by Netty), because
the MSLAB is still onheap, I configure this because i want to keep the
configuration be same as the online
cluster.
I created a table by following command:
hbase(main):001:0> n_splits = 100
hbase(main):002:0> create 'ycsb-test', 'C', {SPLITS => (1..n_splits).map
{|i| "user#{1000+i*(-1000)/n_splits}"}}
and use the workload:
table=ycsb-test
columnfamily=C
recordcount=100
operationcount=100
workload=com.yahoo.ycsb.workloads.CoreWorkload
fieldlength=100
fieldcount=1
#clientbuffering=true
readallfields=true
writeallfields=true
readproportion=0
updateproportion=0
scanproportion=0
insertproportion=1.0
requestdistribution=zipfian
the key configs of RS:
hbase.hregion.memstore.block.multiplier=5
hbase.hregion.memstore.flush.size=268435456
hbase.regionserver.global.memstore.size=0.4
hbase.regionserver.global.memstore.size.lower.limit=0.625
hbase.hregion.compacting.memstore.type=BASIC # NONE in DefaultMemstore.
Command to start the ycsb:
nohup ./bin/ycsb run hbase20-mdh -P workload -s -threads 120 >
hbase20-ssd-put-100-rows 2>&1 &
[jira] [Created] (HBASE-21768) list_quota_table_sizes/list_quota_snapshots should print human readable values for size
xuqinya created HBASE-21768:
---
Summary: list_quota_table_sizes/list_quota_snapshots should print
human readable values for size
Key: HBASE-21768
URL: https://issues.apache.org/jira/browse/HBASE-21768
Project: HBase
Issue Type: Improvement
Components: shell
Reporter: xuqinya
Assignee: xuqinya
Using space quota, list_quota_table_sizes/list_quota_snapshots should print
human readable values for size.
{code:java}
hbase(main):001:0> list_quota_table_sizes
TABLE SIZE
TestTable 110399
t1 5211
hbase(main):002:0> list_quota_snapshots
TABLE USAGE LIMIT IN_VIOLATION POLICY
t1 5211 1073741824 false None
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21769) Support named Connection
Vincent P created HBASE-21769:
-
Summary: Support named Connection
Key: HBASE-21769
URL: https://issues.apache.org/jira/browse/HBASE-21769
Project: HBase
Issue Type: Improvement
Components: Client
Affects Versions: 1.4.0, 1.2.0
Reporter: Vincent P
Metrics as taken from {{MetricsConnection}} are grouped by connection-id which
is defined using {{hashCode}} in {{HConnectionImplementation}}.
This approach has several drawbacks when this connection-id matters
(multi-cluster), which leads to wrong aggregates :
* There is a remote yet uncontrollable possibility of collision
* connection-id is almost certain to change on JVM restart
* connection-id doesn't match with other client machines.
While the {{Connection}} implementation is customizable
("hbase.client.connection.impl"), the original {{HConnectionImplementation}} is
not public, and this default behaviour (toString based on hashCode) doesn't
seem particularly desirable.
I am proposing to change the allow overriding default {{toString()}}
implementation with a configuration-based value.
Side-effects (for users of this feature only) will include a change of name in
connection threads, too (which seems desirable to me).
As the patch is trivial, let me omit it until this issue has been reviewed by a
committer project member.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21770) Should deal with meta table in HRegionLocator.getAllRegionLocations
Duo Zhang created HBASE-21770: - Summary: Should deal with meta table in HRegionLocator.getAllRegionLocations Key: HBASE-21770 URL: https://issues.apache.org/jira/browse/HBASE-21770 Project: HBase Issue Type: Bug Components: Client Reporter: Duo Zhang Missed this one is UT. Let me add the support and also a UT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21771) Cluster key in Master UI is incorrect
Sean Busbey created HBASE-21771:
---
Summary: Cluster key in Master UI is incorrect
Key: HBASE-21771
URL: https://issues.apache.org/jira/browse/HBASE-21771
Project: HBase
Issue Type: Bug
Components: Replication, UI, Usability
Affects Versions: 2.0.0, 2.1.0
Reporter: Sean Busbey
Fix For: 2.1.3
The master UI is supposed to give us a cluster key we can copy/paste to add a
replication peer in the hbase shell. the shell explains that it should look
like this:
{quote}
{code}
For a HBase cluster peer, a cluster key must be provided and is composed like
this:
hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
This gives a full path for HBase to connect to another HBase cluster.
...
hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
"ENABLED"
hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
"DISABLED"
hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
TABLE_CFS => { "table1" => [], "table2" => ["cf1"], "table3" => ["cf1",
"cf2"] }
hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
NAMESPACES => ["ns1", "ns2", "ns3"]
{code}
{quote}
However, on my example cluster with ZK quorum with 3 servers, the master ui
gives this:
{quote}
{code}
Cluster Key busbey-training-1.gce.cloudera.com:2181
busbey-training-2.gce.cloudera.com:2181
busbey-training-3.gce.cloudera.com:2181:/hbase Key to add this cluster as a
peer for replication. Use 'help "add_peer"' in the shell for details.
{code}
{quote}
Note that the quorum members are newline separated instead of comma and that
the port appears on each member instead of after the set of host names.
Workaround is to manually construct the cluster key from the details in the
field. :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21772) hbase cli help does not mention 'zkcli'
Sean Busbey created HBASE-21772:
---
Summary: hbase cli help does not mention 'zkcli'
Key: HBASE-21772
URL: https://issues.apache.org/jira/browse/HBASE-21772
Project: HBase
Issue Type: Bug
Components: Operability, Zookeeper
Affects Versions: 2.1.0
Reporter: Sean Busbey
the hbase command's help doesn't mention zkcli
{code}
hbase
Usage: hbase [] []
Options:
--config DIR Configuration direction to use. Default: ./conf
--hosts HOSTSOverride the list in 'regionservers' file
--auth-as-server Authenticate to ZooKeeper using servers configuration
--internal-classpath Skip attempting to use client facing jars (WARNING:
unstable results between versions)
Commands:
Some commands take arguments. Pass no args or -h for usage.
shell Run the HBase shell
hbckRun the HBase 'fsck' tool. Defaults read-only hbck1.
Pass '-j /path/to/HBCK2.jar' to run hbase-2.x HBCK2.
snapshotTool for managing snapshots
classpath Dump hbase CLASSPATH
mapredcpDump CLASSPATH entries required by mapreduce
pe Run PerformanceEvaluation
ltt Run LoadTestTool
canary Run the Canary tool
version Print the version
regionsplitter Run RegionSplitter tool
rowcounter Run RowCounter tool
cellcounter Run CellCounter tool
pre-upgrade Run Pre-Upgrade validator tool
CLASSNAME Run the class named CLASSNAME
{code}
the command itself still appears to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HBASE-21673) Final sweep of branch-2+ commits for new branch-1 minor (1.5)
[ https://issues.apache.org/jira/browse/HBASE-21673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-21673. Resolution: Fixed All subtasks resolved > Final sweep of branch-2+ commits for new branch-1 minor (1.5) > - > > Key: HBASE-21673 > URL: https://issues.apache.org/jira/browse/HBASE-21673 > Project: HBase > Issue Type: Umbrella >Affects Versions: 1.5.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Major > > Umbrella for backports to branch-1 of suitable changes for a new minor (1.5). > See subtasks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [NOTICE] HBase 1.5.0-SNAPSHOT now available for testing (and updated at least weekly)
Refreshed today (20190124T175254Z) to include HBASE-21475, HBASE-21561, HBASE-21616, HBASE-21675, HBASE-21680, HBASE-21734, HBASE-21735, HBASE-21748, HBASE-21749, and more... This is probably the last snapshot before final work on the first release candidate. On Sat, Jan 12, 2019 at 1:10 PM Andrew Purtell wrote: > Refreshed today (20190112T195839Z) to include HBASE-20716, HBASE-20928, > HBASE-21164, HBASE-21208, HBASE-21325, HBASE-21374, HBASE-21620, > HBASE-21679 (HBASE-6028), HBASE-21687... > > > On Fri, Dec 14, 2018 at 6:59 PM Andrew Purtell > wrote: > >> Refreshed today to include HBASE-21590 (Optimize trySkipToNextColumn in >> StoreScanner a bit) and addendum. >> >> >> On Fri, Dec 7, 2018 at 4:47 PM Andrew Purtell >> wrote: >> >>> In anticipation of the first HBase 1.5 release next month, 1.5.0, I have >>> begun publishing weekly (ish) snapshots. Artifacts are available in >>> Apache's snapshots repository and source and binary tarballs can be >>> downloaded from >>> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.5.0-SNAPSHOT/ . >>> These artifacts are a byproduct of a pre-release RM process and so will be >>> updated frequently, but possibly not daily, up until we have a 1.5.0 >>> release some time in January 2019 (hopefully). >>> >>> Please note this is not a release and not an official artifact of the >>> Apache HBase project, nor the Apache HBase PMC, nor the Apache Software >>> Foundation. This is a set of convenience artifacts made available to HBase >>> developers and potential adopters with no guarantees or warranties. They >>> are not suitable for production usage. They have not undergone any release >>> testing, release process, or formal vote. Should you deploy them in a real >>> application you may need to employ an Einstein-Rosen bridge (if you prefer >>> science fiction) or a seance (if you prefer the fantastic) to recover your >>> data. >>> >>> -- >>> Best regards, >>> Andrew >>> >>> Words like orphans lost among the crosstalk, meaning torn from truth's >>> decrepit hands >>>- A23, Crosstalk >>> >> >> >> -- >> Best regards, >> Andrew >> >> Words like orphans lost among the crosstalk, meaning torn from truth's >> decrepit hands >>- A23, Crosstalk >> > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
