[jira] [Created] (HBASE-19504) Add TimeRange support into checkAndMutate
Chia-Ping Tsai created HBASE-19504: -- Summary: Add TimeRange support into checkAndMutate Key: HBASE-19504 URL: https://issues.apache.org/jira/browse/HBASE-19504 Project: HBase Issue Type: New Feature Reporter: Chia-Ping Tsai Fix For: 2.0.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19503) Fix TestWALOpenAfterDNRollingStart for AsyncFSWAL
Duo Zhang created HBASE-19503: - Summary: Fix TestWALOpenAfterDNRollingStart for AsyncFSWAL Key: HBASE-19503 URL: https://issues.apache.org/jira/browse/HBASE-19503 Project: HBase Issue Type: Bug Components: Replication, wal Reporter: Duo Zhang Assignee: Duo Zhang -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19502) Make sure we have closed all StoreFileScanner if we fail to open any StoreFileScanners
Chia-Ping Tsai created HBASE-19502:
--
Summary: Make sure we have closed all StoreFileScanner if we fail
to open any StoreFileScanners
Key: HBASE-19502
URL: https://issues.apache.org/jira/browse/HBASE-19502
Project: HBase
Issue Type: Sub-task
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
{code:title=StoreFileScanner.java}
public static List
getScannersForStoreFiles(Collection files,
boolean cacheBlocks, boolean usePread, boolean isCompaction, boolean
canUseDrop,
ScanQueryMatcher matcher, long readPt, boolean isPrimaryReplica) throws
IOException {
List scanners = new
ArrayList(files.size());
List sorted_files = new ArrayList<>(files);
Collections.sort(sorted_files, StoreFile.Comparators.SEQ_ID);
for (int i = 0; i < sorted_files.size(); i++) {
StoreFile.Reader r = sorted_files.get(i).createReader(canUseDrop);
r.setReplicaStoreFile(isPrimaryReplica);
StoreFileScanner scanner = r.getStoreFileScanner(cacheBlocks, usePread,
isCompaction, readPt,
i, matcher != null ? !matcher.hasNullColumnInQuery() : false);
scanners.add(scanner);
}
return scanners;
}
{code}
The missed decrement of ref count will obstruct the cleanup of compacted files.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-16890. --- Resolution: Fixed Hadoop Flags: Reviewed Resolving. I think you all -- [~Apache9] in particular -- fixed the perf diff. > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Blocker > Fix For: 2.0.0-beta-1 > > Attachments: AsyncWAL_disruptor.patch, AsyncWAL_disruptor_1 > (2).patch, AsyncWAL_disruptor_3.patch, AsyncWAL_disruptor_3.patch, > AsyncWAL_disruptor_4.patch, AsyncWAL_disruptor_6.patch, > HBASE-16890-rc-v2.patch, HBASE-16890-rc-v3.patch, > HBASE-16890-remove-contention-v1.patch, HBASE-16890-remove-contention.patch, > Screen Shot 2016-10-25 at 7.34.47 PM.png, Screen Shot 2016-10-25 at 7.39.07 > PM.png, Screen Shot 2016-10-25 at 7.39.48 PM.png, Screen Shot 2016-11-04 at > 5.21.27 PM.png, Screen Shot 2016-11-04 at 5.30.18 PM.png, async.svg, > classic.svg, contention.png, contention_defaultWAL.png, > ycsb_FSHlog.vs.Async.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19501) [AMv2] Retain assignment across restarts
stack created HBASE-19501: - Summary: [AMv2] Retain assignment across restarts Key: HBASE-19501 URL: https://issues.apache.org/jira/browse/HBASE-19501 Project: HBase Issue Type: Sub-task Components: Region Assignment Reporter: stack Assignee: stack Fix For: 2.0.0-beta-1 Working with replicas and the parent test in particular, I learned a few interesting things: # It is hard to test if we retain assignments because our little minicluster gives RegionServers new ports on restart foiling our means of recognizing new instance of a server by checking hostname+port (and ensuring the startcode is larger). # Some of our tests like the parent test depended on retaining assignment across restarts. # As said in parent issue, master used to be last to go down when we did a controlled cluster shutdown. We lost that when we moved to AMv2. # When we do a cluster shutdown, the RegionServers close down the Regions, not the Master as is usual in AMv2 (Master wants to do all assign ops in AMv2). This means that the Master is surprised when it gets notification of CLOSE ops that it did not initiate. Usually on CLOSE, Master updates meta with the CLOSE state. On cluster shutdown we are not doing this. # So, on restart, we read meta and we see all regions still in OPEN state so we think the cluster crashed down so we go and do ServerCrashProcedure. Which hoses our ability to retain assign. Some experiments: # I can make the Master stay up so it is last to go down # This makes it so we no longer spew the logs with failed transition messages because Master is not up to receive the CLOSE transitions. # I hacked in means of telling minicluster ports it should use on start; helps fake case of new RS instances # It is hard to tell the difference between a clean shutdown and a crash down. It is dangerous if we get the call wrong. Currently, given that we just let ServerCrashProcedure deal with it -- the safest option -- one experiment is that when it goes to assign the regions that were on the crashed server, rather than round robin, instead we should look and see if new instance of old location and if so, just give it al lthe regions. That'd retain locality. This seems to work. Problem is that SCP is doing assignment. Ideally balancer would do it. Let me put up a patch that retains assignment across restart (somehow). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: [VOTE] The second HBase 1.4.0 release candidate (RC1) is available
Times are in milliseconds. On Tue, Dec 12, 2017 at 5:50 PM, Andrew Purtell wrote: > Here are results from a YCSB comparison between 1.2.6 and 1.4.0 RC1: > > https://bigdatasf.s3.amazonaws.com/assets/ycsb_1.2.6_to_1.4.0RC1.png > https://bigdatasf.s3.amazonaws.com/assets/ycsb_1.2.6_to_1.4.0RC1.xlsx > > [image: Inline image 1] > > They are pretty closely matched but generally 1.4.0 RC1 shows superior > results. > > [R] and [W] mean different things depending on YCSB workload. They will be > obvious except for Workload F, where [R] is READ and [W] is UPDATE. I > didn't include numbers for READ-MODIFY-WRITE. > > Cluster: 1 master, 5 regionservers, 1 client > AWS Instance Type: c3.4xlarge > Hadoop: 2.7.4 > OS: Amazon Linux AMI 2017.09, kernel 4.4.51-40.58.amzn1.x86_64 > > > On Fri, Dec 8, 2017 at 5:50 PM, Andrew Purtell > wrote: > >> The second HBase 1.4.0 release candidate (RC1) is available for download >> at https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.0RC1/ and >> Maven artifacts are available in the temporary repository >> https://repository.apache.org/content/repositories/orgapachehbase-1186/ . >> >> The git tag corresponding to the candidate is '1.4.0RC1' (10b9b9fae6). >> >> A detailed source and binary compatibility report for this release is >> available for your review at https://dist.apache.org/repos/ >> dist/dev/hbase/hbase-1.4.0RC1/hbase-1.3.1-1.4.0RC1_compatibi >> lity_report.html . All reported compatibility issues should comply with >> policy but please review them carefully. >> >> A list of the 660 issues resolved in this release can be found at >> https://s.apache.org/OErT . >> >> The changes since RC0 are: >> >> * [HBASE-19180] - Remove unused imports from AlwaysPasses >> * [HBASE-19373] - Fix Checkstyle error in hbase-annotations >> * [HBASE-19435] - Reopen Files for ClosedChannelException in >> BucketCache >> * [HBASE-19465] - Required httpcore and httpclient jars not included >> in binary distribution >> * [HBASE-19467] - rsgroups shell commands don't properly display >> elapsed time >> >> Please try out the candidate and vote +1/0/-1. >> >> This vote will be open for at least 72 hours. Unless objection I will try >> to close it Monday December 18, 2017 if we have sufficient votes. >> >> Prior to making this announcement I made the following preflight checks >> to 1.4.0RC0 (3d571827cb): >> >> RAT check passes (7u80) >> Unit test suite passes (8u131) >> LTT load 1M rows with 100% verification and 20% updates (8u131) >> PE randomWrite, randomRead, scanRange100 (8u131) >> 100M rows ITBLL (8u131) >> >> and the following preflight checks to 1.4.0RC1 (10b9b9fae6): >> >> RAT check passes (7u80) >> Unit test suite passes (8u131) >> >> Between now and when I want to close the vote I'll write up human >> readable release notes for the release announcement as promised. >> >> I also have agreed to run a scale ITBLL test, a performance comparison >> with 1.2 using YCSB, a performance comparison with 1.2 using PE, and an >> analysis of code and allocation hot spot changes from 1.2, all of which I >> will publish when available and factor in to my vote. >> >> -- >> Best regards, >> Andrew >> >> > > > -- > 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
Re: [VOTE] The second HBase 1.4.0 release candidate (RC1) is available
Here are results from a YCSB comparison between 1.2.6 and 1.4.0 RC1: https://bigdatasf.s3.amazonaws.com/assets/ycsb_1.2.6_to_1.4.0RC1.png https://bigdatasf.s3.amazonaws.com/assets/ycsb_1.2.6_to_1.4.0RC1.xlsx [image: Inline image 1] They are pretty closely matched but generally 1.4.0 RC1 shows superior results. [R] and [W] mean different things depending on YCSB workload. They will be obvious except for Workload F, where [R] is READ and [W] is UPDATE. I didn't include numbers for READ-MODIFY-WRITE. Cluster: 1 master, 5 regionservers, 1 client AWS Instance Type: c3.4xlarge Hadoop: 2.7.4 OS: Amazon Linux AMI 2017.09, kernel 4.4.51-40.58.amzn1.x86_64 On Fri, Dec 8, 2017 at 5:50 PM, Andrew Purtell wrote: > The second HBase 1.4.0 release candidate (RC1) is available for download > at https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.0RC1/ and Maven > artifacts are available in the temporary repository > https://repository.apache.org/content/repositories/orgapachehbase-1186/ . > > The git tag corresponding to the candidate is '1.4.0RC1' (10b9b9fae6). > > A detailed source and binary compatibility report for this release is > available for your review at https://dist.apache.org/repos/ > dist/dev/hbase/hbase-1.4.0RC1/hbase-1.3.1-1.4.0RC1_ > compatibility_report.html . All reported compatibility issues should > comply with policy but please review them carefully. > > A list of the 660 issues resolved in this release can be found at > https://s.apache.org/OErT . > > The changes since RC0 are: > > * [HBASE-19180] - Remove unused imports from AlwaysPasses > * [HBASE-19373] - Fix Checkstyle error in hbase-annotations > * [HBASE-19435] - Reopen Files for ClosedChannelException in > BucketCache > * [HBASE-19465] - Required httpcore and httpclient jars not included > in binary distribution > * [HBASE-19467] - rsgroups shell commands don't properly display > elapsed time > > Please try out the candidate and vote +1/0/-1. > > This vote will be open for at least 72 hours. Unless objection I will try > to close it Monday December 18, 2017 if we have sufficient votes. > > Prior to making this announcement I made the following preflight checks to > 1.4.0RC0 (3d571827cb): > > RAT check passes (7u80) > Unit test suite passes (8u131) > LTT load 1M rows with 100% verification and 20% updates (8u131) > PE randomWrite, randomRead, scanRange100 (8u131) > 100M rows ITBLL (8u131) > > and the following preflight checks to 1.4.0RC1 (10b9b9fae6): > > RAT check passes (7u80) > Unit test suite passes (8u131) > > Between now and when I want to close the vote I'll write up human readable > release notes for the release announcement as promised. > > I also have agreed to run a scale ITBLL test, a performance comparison > with 1.2 using YCSB, a performance comparison with 1.2 using PE, and an > analysis of code and allocation hot spot changes from 1.2, all of which I > will publish when available and factor in to my vote. > > -- > Best regards, > Andrew > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
[jira] [Resolved] (HBASE-17425) Fix calls to deprecated APIs in TestUpdateConfiguration
[
https://issues.apache.org/jira/browse/HBASE-17425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Hentschel resolved HBASE-17425.
---
Resolution: Fixed
Closing this one. All changes to 1.x branches are reverted.
> Fix calls to deprecated APIs in TestUpdateConfiguration
> ---
>
> Key: HBASE-17425
> URL: https://issues.apache.org/jira/browse/HBASE-17425
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Reporter: Jan Hentschel
>Assignee: Jan Hentschel
>Priority: Trivial
> Fix For: 3.0.0, 2.0.0-beta-1
>
> Attachments: HBASE-17425.master.001.patch
>
>
> Currently there are two calls to the deprecated method
> {code:java}HBaseTestingUtil.getHBaseAdmin(){code} in
> *TestUpdateConfiguration*. These calls should be changed to
> {code:java}HBaseTestingUtil.getAdmin(){code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19500) Make RSGroupInfo immutable
Appy created HBASE-19500:
Summary: Make RSGroupInfo immutable
Key: HBASE-19500
URL: https://issues.apache.org/jira/browse/HBASE-19500
Project: HBase
Issue Type: Bug
Reporter: Appy
HBASE-19483 added CP hooks to expose RSGroupInfo.
First, we should at least change [hbase-client] RSGroupInfo to immutable +
builder pattern like we have done for so many other things.
What say [~Apache9]
Then, few questions need figuring out:
- Should hooks be allowed to change RSGroupInfo.
Probably not? Then making it immutable would be necessary and sufficient
- Can we remove {{if(((MasterEnvironment)getEnvironment()).supportGroupCPs) }}
in so many places since CP in 2.0 are already broken left and right (and we'll
have to solve legacy issue more holistically) What say [~anoop.hbase]?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19499) RegionMover#stripMaster is not longer necessary in RegionMover
Esteban Gutierrez created HBASE-19499:
-
Summary: RegionMover#stripMaster is not longer necessary in
RegionMover
Key: HBASE-19499
URL: https://issues.apache.org/jira/browse/HBASE-19499
Project: HBase
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Esteban Gutierrez
Probably this is the first of few issues found during some tests with
RegionMover. After HBASE-13014 we ship the new RegionMover tool but it
currently assumes that master will be hosting regions so it attempts to remove
master from the list and that causes an issue similar to this:
{code}
17/12/12 11:01:06 WARN util.RegionMover: Could not remove master from list of RS
java.lang.Exception: Server host1.example.com:22001 is not in list of online
servers(Offline/Incorrect)
at
org.apache.hadoop.hbase.util.RegionMover.stripServer(RegionMover.java:818)
at
org.apache.hadoop.hbase.util.RegionMover.stripMaster(RegionMover.java:757)
at
org.apache.hadoop.hbase.util.RegionMover.access$1800(RegionMover.java:78)
at
org.apache.hadoop.hbase.util.RegionMover$Unload.call(RegionMover.java:339)
at
org.apache.hadoop.hbase.util.RegionMover$Unload.call(RegionMover.java:314)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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}
Basicaly
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19498) Fix findbugs and error-prone warnings in hbase-client (branch-2)
Peter Somogyi created HBASE-19498: - Summary: Fix findbugs and error-prone warnings in hbase-client (branch-2) Key: HBASE-19498 URL: https://issues.apache.org/jira/browse/HBASE-19498 Project: HBase Issue Type: Sub-task Reporter: Peter Somogyi Assignee: Peter Somogyi -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-17016) Reimplement per-region latency histogram metrics
[
https://issues.apache.org/jira/browse/HBASE-17016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-17016.
Resolution: Won't Fix
We have replaced per-region metrics with table metrics (HBASE-19285)
> Reimplement per-region latency histogram metrics
>
>
> Key: HBASE-17016
> URL: https://issues.apache.org/jira/browse/HBASE-17016
> Project: HBase
> Issue Type: Task
> Components: metrics
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Andrew Purtell
>
> Follow up from HBASE-10656, where [~enis] says:
> {quote}
> the main problem is that we have A LOT of per-region metrics that are latency
> histograms. These latency histograms create many many Counter / LongAdder
> objects. We should get rid of per-region latencies and maybe look at reducing
> the per-region metric overhead.
> {quote}
> And [~ghelmling] gives us a good candidate to implement pre-region latency
> histograms [HdrHistogram|https://github.com/HdrHistogram/HdrHistogram].
> Let's consider removing the per-region latency histograms and reimplement
> using HdrHistogram.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19497) Fix findbugs and error-prone warnings in hbase-common (branch-2)
Peter Somogyi created HBASE-19497: - Summary: Fix findbugs and error-prone warnings in hbase-common (branch-2) Key: HBASE-19497 URL: https://issues.apache.org/jira/browse/HBASE-19497 Project: HBase Issue Type: Sub-task Affects Versions: 2.0.0-alpha-4 Reporter: Peter Somogyi Assignee: Peter Somogyi Fix For: 2.0.0-beta-1 In hbase-common fix important findbugs and error-prone warnings on branch-2 / master. Start with a forward port pass from HBASE-19239. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19496) Reusing the ByteBuffer in rpc layer corrupt the ServerLoad and RegionLoad
Chia-Ping Tsai created HBASE-19496:
--
Summary: Reusing the ByteBuffer in rpc layer corrupt the
ServerLoad and RegionLoad
Key: HBASE-19496
URL: https://issues.apache.org/jira/browse/HBASE-19496
Project: HBase
Issue Type: Bug
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Priority: Blocker
Fix For: 2.0.0-beta-1
{{ServerLoad}} and {{RegionLoad}} store the pb object internally but the
bytebuffer of pb object may be reused in rpc layer. Hence, the {{ServerLoad}}
and {{RegionLoad}} which saved by {{HMaster}} will be corrupted if the
bytebuffer backed is modified.
This issue doesn't happen on branch-1.
# netty server was introduced in 2.0 (see HBASE-17263)
# reusing bytebuffer to read RPC requests was introduced in 2.0 (see
HBASE-15788)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
Re: [VOTE] The second HBase 1.4.0 release candidate (RC1) is available
+1 I ran the same tests as before: - signatures, checksums are good, - building and unit tests pass (8u112), - shell functionalities are ok, - RS groups work as expected. Best regards, Balazs On Sat, Dec 9, 2017 at 4:37 AM, Guanghao Zhang wrote: > +1 (non-binding) > > hbase-1.4.0-bin.tar.gz (jdk8u144) > - Verified md5sum: ok > - Start HBase in standalone mode: ok > - Verified with shell, create/disable/enable/drop/get/put/scan/delete: ok > - Checked master/regionserver/region Web UI: ok > > hbase-1.4.0-src.tar.gz (jdk8u144) > - Verified md5sum: ok > - Build tarball: ok > - Start HBase in standalone mode: ok > - Verified with shell, create/disable/enable/drop/get/put/scan/delete: ok > - Checked master/regionserver/region Web UI: ok > > One trivial bug for Table ui: the compaction state will show a exception > message when the table is disabled. Will fill a issue for this. > > Thanks. > > 2017-12-09 9:50 GMT+08:00 Andrew Purtell : > > > The second HBase 1.4.0 release candidate (RC1) is available for download > > at https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.0RC1/ and > Maven > > artifacts are available in the temporary repository > > https://repository.apache.org/content/repositories/orgapachehbase-1186/ > . > > > > The git tag corresponding to the candidate is '1.4.0RC1' (10b9b9fae6). > > > > A detailed source and binary compatibility report for this release is > > available for your review at > > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.0RC1/ > > hbase-1.3.1-1.4.0RC1_compatibility_report.html > > . All reported compatibility issues should comply with policy but please > > review them carefully. > > > > A list of the 660 issues resolved in this release can be found at > > https://s.apache.org/OErT . > > > > The changes since RC0 are: > > > > * [HBASE-19180] - Remove unused imports from AlwaysPasses > > * [HBASE-19373] - Fix Checkstyle error in hbase-annotations > > * [HBASE-19435] - Reopen Files for ClosedChannelException in > > BucketCache > > * [HBASE-19465] - Required httpcore and httpclient jars not included > in > > binary distribution > > * [HBASE-19467] - rsgroups shell commands don't properly display > > elapsed time > > > > Please try out the candidate and vote +1/0/-1. > > > > This vote will be open for at least 72 hours. Unless objection I will try > > to close it Monday December 18, 2017 if we have sufficient votes. > > > > Prior to making this announcement I made the following preflight checks > to > > 1.4.0RC0 (3d571827cb): > > > > RAT check passes (7u80) > > Unit test suite passes (8u131) > > LTT load 1M rows with 100% verification and 20% updates (8u131) > > PE randomWrite, randomRead, scanRange100 (8u131) > > 100M rows ITBLL (8u131) > > > > and the following preflight checks to 1.4.0RC1 (10b9b9fae6): > > > > RAT check passes (7u80) > > Unit test suite passes (8u131) > > > > Between now and when I want to close the vote I'll write up human > readable > > release notes for the release announcement as promised. > > > > I also have agreed to run a scale ITBLL test, a performance comparison > with > > 1.2 using YCSB, a performance comparison with 1.2 using PE, and an > > analysis of code and allocation hot spot changes from 1.2, all of which I > > will publish when available and factor in to my vote. > > > > -- > > Best regards, > > Andrew > > >
[jira] [Created] (HBASE-19495) Fix failed ut TestShell
Guanghao Zhang created HBASE-19495: -- Summary: Fix failed ut TestShell Key: HBASE-19495 URL: https://issues.apache.org/jira/browse/HBASE-19495 Project: HBase Issue Type: Bug Reporter: Guanghao Zhang Failed on master branch. Need debug. [INFO] Running org.apache.hadoop.hbase.client.TestShell [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 722.737 s <<< FAILURE! - in org.apache.hadoop.hbase.client.TestShell [ERROR] testRunShellTests(org.apache.hadoop.hbase.client.TestShell) Time elapsed: 699.473 s <<< ERROR! org.jruby.embed.EvalFailedException: (RuntimeError) Shell unit tests failed. Check output file for details. at org.apache.hadoop.hbase.client.TestShell.testRunShellTests(TestShell.java:36) Caused by: org.jruby.exceptions.RaiseException: (RuntimeError) Shell unit tests failed. Check output file for details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
