date:20150812

[jira] [Commented] (HBASE-14203) remove duplicate code getTableDescriptor in HTable

2015-08-12 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-14203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693580#comment-14693580
 ] 

Hadoop QA commented on HBASE-14203:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12750059/HBASE-14203_v4.patch
  against master branch at commit aa3538f80278f5c0ba1bc8ca903066fa02ac79ec.
  ATTACHMENT ID: 12750059

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

{color:green}+1 hadoop versions{color}. The patch compiles with all 
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0)

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 protoc{color}.  The applied patch does not increase the 
total number of protoc compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:red}-1 checkstyle{color}.  The applied patch generated 
1861 checkstyle errors (more than the master's current 1857 errors).

{color:green}+1 findbugs{color}.  The patch does not introduce any  new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

  {color:green}+1 site{color}.  The mvn post-site goal succeeds with this patch.

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/15067//testReport/
Release Findbugs (version 2.0.3)warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/15067//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors: 
https://builds.apache.org/job/PreCommit-HBASE-Build/15067//artifact/patchprocess/checkstyle-aggregate.html

Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/15067//console

This message is automatically generated.

 remove duplicate code getTableDescriptor in HTable
 --

 Key: HBASE-14203
 URL: https://issues.apache.org/jira/browse/HBASE-14203
 Project: HBase
  Issue Type: Improvement
Reporter: Heng Chen
Priority: Trivial
 Attachments: HBASE-14203.patch, HBASE-14203_v2.patch, 
 HBASE-14203_v3.patch, HBASE-14203_v4.patch


 As TODO in comment said, 
 {{HTable.getTableDescriptor}} is same as {{HAdmin.getTableDescriptor}}. 
 remove the duplicate code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14078) improve error message when HMaster can't bind to port

2015-08-12 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-14078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693668#comment-14693668
 ] 

stack commented on HBASE-14078:
---

Formatting is a little off. Please check.

Do you have example of what the emission looks like now?

Whatever the IOE exception that comes up out of setting up the rpc server, we 
will always have this suffix about how to config port. Will it always be a port 
issue? Perhaps work on BindException only? And only if 'Address in use'?

The changes in HMaster.java do not seem to make for the same emission. Is that 
intentional? For example, before patch, if an Exception, we used to  
e.getCause().getMessage() if non-null but now if I read it right, we do 
e.toString



 improve error message when HMaster can't bind to port
 -

 Key: HBASE-14078
 URL: https://issues.apache.org/jira/browse/HBASE-14078
 Project: HBase
  Issue Type: Improvement
  Components: master
Affects Versions: 2.0.0
Reporter: Sean Busbey
Assignee: Matt Warhaftig
  Labels: beginner
 Fix For: 2.0.0

 Attachments: hbase-14708-v1.patch, hbase-14708-v2.patch


 When the master fails to start becahse hbase.master.port is already taken, 
 the log messages could make it easier to tell.
 {quote}
 2015-07-14 13:10:02,667 INFO  [main] regionserver.RSRpcServices: 
 master/master01.example.com/10.20.188.121:16000 server-side HConnection 
 retries=350
 2015-07-14 13:10:02,879 INFO  [main] ipc.SimpleRpcScheduler: Using deadline 
 as user call queue, count=3
 2015-07-14 13:10:02,895 ERROR [main] master.HMasterCommandLine: Master exiting
 java.lang.RuntimeException: Failed construction of Master: class 
 org.apache.hadoop.hbase.master.HMaster
 at 
 org.apache.hadoop.hbase.master.HMaster.constructMaster(HMaster.java:2258)
 at 
 org.apache.hadoop.hbase.master.HMasterCommandLine.startMaster(HMasterCommandLine.java:234)
 at 
 org.apache.hadoop.hbase.master.HMasterCommandLine.run(HMasterCommandLine.java:140)
 at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
 at 
 org.apache.hadoop.hbase.util.ServerCommandLine.doMain(ServerCommandLine.java:126)
 at org.apache.hadoop.hbase.master.HMaster.main(HMaster.java:2272)
 Caused by: java.net.BindException: Address already in use
 at sun.nio.ch.Net.bind0(Native Method)
 at sun.nio.ch.Net.bind(Net.java:444)
 at sun.nio.ch.Net.bind(Net.java:436)
 at 
 sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
 at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
 at org.apache.hadoop.hbase.ipc.RpcServer.bind(RpcServer.java:2513)
 at 
 org.apache.hadoop.hbase.ipc.RpcServer$Listener.init(RpcServer.java:599)
 at org.apache.hadoop.hbase.ipc.RpcServer.init(RpcServer.java:2000)
 at 
 org.apache.hadoop.hbase.regionserver.RSRpcServices.init(RSRpcServices.java:919)
 at 
 org.apache.hadoop.hbase.master.MasterRpcServices.init(MasterRpcServices.java:211)
 at 
 org.apache.hadoop.hbase.master.HMaster.createRpcServices(HMaster.java:509)
 at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.init(HRegionServer.java:535)
 at org.apache.hadoop.hbase.master.HMaster.init(HMaster.java:351)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
 at 
 org.apache.hadoop.hbase.master.HMaster.constructMaster(HMaster.java:2253)
 ... 5 more
 {quote}
 I recognize that the RSRpcServices log message shows port 16000, but I 
 don't know why a new operator would. Additionally, it'd be nice to tell them 
 that the port is controlled by {{hbase.master.port}}. Maybe give a hint on 
 how to see what's using the port. Could be too os-dist specific?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-13838) Fix shared TaskStatusTmpl.jamon issues (coloring, content, etc.)

2015-08-12 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693628#comment-14693628
 ] 

stack commented on HBASE-13838:
---

Do you have a gif of what page looks like after your changes [~mwarhaftig] 
including what the JSON toString looks like? Thanks.

 Fix shared TaskStatusTmpl.jamon issues (coloring, content, etc.)
 

 Key: HBASE-13838
 URL: https://issues.apache.org/jira/browse/HBASE-13838
 Project: HBase
  Issue Type: Bug
  Components: UI
Affects Versions: 1.1.0
Reporter: Lars George
Assignee: Matt Warhaftig
  Labels: beginner
 Fix For: 2.0.0, 1.3.0

 Attachments: hbase-13838-v1.patch


 There are a few issues with the shared TaskStatusTmpl:
 - Client operations tab is always empty 
 For Master this is expected, but for RegionServers there is never anything 
 listed either. Fix for RS status page (probably caused by params not 
 containing Operation subclass anymore, but some PB generated classes?)
 - Hide “Client Operations” tab for master UI
 Since operations are RS only. Or we fix this and make other calls show here.
 - The alert-error for aborted tasks is not set in CSS at all
 When a task was aborted it should be amber or red, but the assigned style is 
 not in any of the linked stylesheets (abort-error). Add.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-13708) PE - Add option to specify the range

2015-08-12 Thread stack (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-13708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-13708:
--
Attachment: hbase-13708-v2.patch

Resubmit (You resubmit by reattaching [~mwarhaftig] -- just FYI).

I've always wanted to have this option but was always too lazy to implement it.

 PE - Add option to specify the range
 

 Key: HBASE-13708
 URL: https://issues.apache.org/jira/browse/HBASE-13708
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.1
Reporter: Jean-Marc Spaggiari
Assignee: Matt Warhaftig
Priority: Minor
  Labels: beginner
 Fix For: 2.0.0, 1.3.0

 Attachments: HBASE-13708-master_v1.patch, hbase-13708-v2.patch, 
 hbase-13708-v2.patch


 When specifying --rows=YYY for randomReads in PE, it will read YYY rows but 
 only betweem 0 and YYY.
 We might want to read YYY rows randomly between 0 and ZZZ.
 YYY should only be the number of rows we want to ready. Not the high range.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-13708) PE - Add option to specify the range

2015-08-12 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693634#comment-14693634
 ] 

stack commented on HBASE-13708:
---

You have output to show this works [~mwarhaftig]? Thanks.

 PE - Add option to specify the range
 

 Key: HBASE-13708
 URL: https://issues.apache.org/jira/browse/HBASE-13708
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.1
Reporter: Jean-Marc Spaggiari
Assignee: Matt Warhaftig
Priority: Minor
  Labels: beginner
 Fix For: 2.0.0, 1.3.0

 Attachments: HBASE-13708-master_v1.patch, hbase-13708-v2.patch, 
 hbase-13708-v2.patch


 When specifying --rows=YYY for randomReads in PE, it will read YYY rows but 
 only betweem 0 and YYY.
 We might want to read YYY rows randomly between 0 and ZZZ.
 YYY should only be the number of rows we want to ready. Not the high range.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-13966) Limit column width in table.jsp

2015-08-12 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693644#comment-14693644
 ] 

stack commented on HBASE-13966:
---

[~mwarhaftig] You have example of your fix in effect -- images? -- of how it 
addresses [~jmspaggi]'s issue? Thanks.

 Limit column width in table.jsp
 ---

 Key: HBASE-13966
 URL: https://issues.apache.org/jira/browse/HBASE-13966
 Project: HBase
  Issue Type: Bug
  Components: UI
Affects Versions: 1.1.0.1
Reporter: Jean-Marc Spaggiari
Assignee: Matt Warhaftig
Priority: Minor
  Labels: beginner
 Attachments: hbase-13966-v1.patch


 In table.jsp, for tables with very wide keys like URLs, the page can be very 
 wide. On my own cluster, this page is 8 screens wide, almost un-usable.
 Might be good to have a way to resize the columns, or wrap the long keys or 
 truncate them, or anything else. When we want to look at the last colums, 
 this is a big difficult.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-13839) Fix AssgnmentManagerTmpl.jamon issues (coloring, content etc.)

2015-08-12 Thread stack (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-13839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693638#comment-14693638
]

stack commented on HBASE-13839:
---

You have images that show these fixes in operation [~mwarhaftig]? Or else, I
could try and apply this and your other UI fixes locally and check they do the
right thing.

Fix AssgnmentManagerTmpl.jamon issues (coloring, content etc.)
--

Key: HBASE-13839
URL: https://issues.apache.org/jira/browse/HBASE-13839
Project: HBase
Issue Type: Bug
Components: master, UI
Affects Versions: 1.1.0
Reporter: Lars George
Assignee: Matt Warhaftig
Labels: beginner
Fix For: 2.0.0, 1.3.0

Attachments: hbase-13839-v1.patch

The template for the RIT in the Master status page,
AssignmentManagerTmpl.jamon) has a few issues:
- The oldest RIT should not be _red_, looks like a failed entry
The RIT entries should be for example yellow/amber when over the threshold
time, and red if 2x the threshold - or red for the oldest once over the
threshold.
- Region count over RIT threshold should only be colored if 0
The summary line (first of two) should not be colored unless there is a value
0 in it.
- Color is overriden by table-stripped CSS style!
The Bootstrap stylesheet cancels out the hardcoded coloring! The
table-stripped resets the conditional coloring and should be fixed. Best is
to use alert-warning etc. that come from the Bootstrap theme stylesheet.
That should maybe already work in combination with the table-stripped from
the same.
- Should sort descending by time
Currently the list of regions is sorted by encoded region name. Better is to
have the table sorted by RIT time descending.
We should also think about a pagination option for the currently hardcoded
100 entries max. Maybe a separate issue?

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14147) REST Support for Namespaces

2015-08-12 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-14147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693674#comment-14693674
 ] 

stack commented on HBASE-14147:
---

Looks like a nice fat addition. On skim, looks nicely done. Manipulating 
namespace from REST is a little on the exotic side though I'd say. What is the 
use case? Any REST heads want to check this out?



 REST Support for Namespaces
 ---

 Key: HBASE-14147
 URL: https://issues.apache.org/jira/browse/HBASE-14147
 Project: HBase
  Issue Type: Sub-task
  Components: REST
Affects Versions: 1.1.1
Reporter: Rick Kellogg
Assignee: Matt Warhaftig
Priority: Minor
 Attachments: hbase-14147-v1.patch


 Expand REST services to include addition features:
 * Create namespace
 * Alter namespace
 * Describe namespace
 * Drop namespace
 * List tables in a specific namespace
 * List all namespaces.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-14150) Add BulkLoad functionality to HBase-Spark Module

2015-08-12 Thread Ted Yu (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-14150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-14150:
---
  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

Thanks for the patch, Ted.

Thanks for the review, Andrew.

 Add BulkLoad functionality to HBase-Spark Module
 

 Key: HBASE-14150
 URL: https://issues.apache.org/jira/browse/HBASE-14150
 Project: HBase
  Issue Type: New Feature
  Components: spark
Reporter: Ted Malaska
Assignee: Ted Malaska
 Fix For: 2.0.0

 Attachments: HBASE-14150.1.patch, HBASE-14150.2.patch, 
 HBASE-14150.3.patch, HBASE-14150.4.patch, HBASE-14150.5.patch


 Add on to the work done in HBASE-13992 to add functionality to do a bulk load 
 from a given RDD.
 This will do the following:
 1. figure out the number of regions and sort and partition the data correctly 
 to be written out to HFiles
 2. Also unlike the MR bulkload I would like that the columns to be sorted in 
 the shuffle stage and not in the memory of the reducer.  This will allow this 
 design to support super wide records with out going out of memory.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14150) Add BulkLoad functionality to HBase-Spark Module

2015-08-12 Thread Ted Malaska (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-14150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693714#comment-14693714
 ] 

Ted Malaska commented on HBASE-14150:
-

Thanks guys,

Super excited.  Now one more big one 14181 and it will be much smaller jira and 
documentation for awhile.

 Add BulkLoad functionality to HBase-Spark Module
 

 Key: HBASE-14150
 URL: https://issues.apache.org/jira/browse/HBASE-14150
 Project: HBase
  Issue Type: New Feature
  Components: spark
Reporter: Ted Malaska
Assignee: Ted Malaska
 Fix For: 2.0.0

 Attachments: HBASE-14150.1.patch, HBASE-14150.2.patch, 
 HBASE-14150.3.patch, HBASE-14150.4.patch, HBASE-14150.5.patch


 Add on to the work done in HBASE-13992 to add functionality to do a bulk load 
 from a given RDD.
 This will do the following:
 1. figure out the number of regions and sort and partition the data correctly 
 to be written out to HFiles
 2. Also unlike the MR bulkload I would like that the columns to be sorted in 
 the shuffle stage and not in the memory of the reducer.  This will allow this 
 design to support super wide records with out going out of memory.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14201) hbck should not take a lock unless fixing errors

2015-08-12 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-14201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14694225#comment-14694225
 ] 

Hudson commented on HBASE-14201:


FAILURE: Integrated in HBase-TRUNK #6719 (See 
[https://builds.apache.org/job/HBase-TRUNK/6719/])
HBASE-14201 hbck should not take a lock unless fixing errors (eclark: rev 
0c63d415d9d23a80ec3b8f454bbf4748de4a1a78)
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/util/hbck/HbckTestingUtil.java
* hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsck.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java


 hbck should not take a lock unless fixing errors
 

 Key: HBASE-14201
 URL: https://issues.apache.org/jira/browse/HBASE-14201
 Project: HBase
  Issue Type: Bug
  Components: hbck, util
Affects Versions: 2.0.0, 1.3.0
Reporter: Simon Law
Assignee: Simon Law
 Fix For: 2.0.0, 1.2.0

 Attachments: HBASE-14201-v0.patch, HBASE-14201-v1.patch


 By default, hbck is run in a read-only checker mode. In this case, it is
 sensible to let others run. By default, the balancer is left alone,
 which may cause spurious errors, but cannot leave the balancer in a bad
 state. It is dangerous to leave the balancer by accident, so it is only
 ever enabled after fixing, it will never be forced off because of
 racing.
 When hbck is run in fixer mode, it must take an exclusive lock and
 disable the balancer, or all havoc will break loose.
 If you want to stop hbck from running in parallel, the -exclusive flag
 will create the lock file. If you want to force -disableBalancer, that
 option is available too. This makes more semantic sense than -noLock and
 -noSwitchBalancer, respectively.
 This task is related to HBASE-14092.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14209) TestShell visibility tests failing

2015-08-12 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-14209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14694323#comment-14694323
 ] 

Hudson commented on HBASE-14209:


FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #1030 (See 
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/1030/])
HBASE-14209 TestShell visibility tests failing (apurtell: rev 
cddb28ef9fae67087280b99c4323945e43fba000)
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityLabelsCache.java


 TestShell visibility tests failing
 --

 Key: HBASE-14209
 URL: https://issues.apache.org/jira/browse/HBASE-14209
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.98.14
Reporter: Andrew Purtell
Assignee: Andrew Purtell
 Fix For: 2.0.0, 0.98.14, 1.0.2, 1.2.0, 1.1.2, 1.3.0

 Attachments: HBASE-14209-0.98.patch


 This is after HBASE-14105  but we've seen this earlier where adding ruby 
 units to the shell tests can cause the visibility tests to fail inexplicably. 
 We can't just avoid adding ruby units to TestShell in 0.98 so figure out the 
 root cause and fix or disable these. 
 {noformat}
   1) Error:
 test_The_get/put_methods_should_work_for_data_written_with_Visibility(Hbase::VisibilityLabelsAdminMethodsTest):
 NativeException: junit.framework.AssertionFailedError: Waiting timed out 
 after [10,000] msec
 junit/framework/Assert.java:57:in `fail'
 org/apache/hadoop/hbase/Waiter.java:193:in `waitFor'
 org/apache/hadoop/hbase/Waiter.java:128:in `waitFor'
 org/apache/hadoop/hbase/HBaseTestingUtility.java:3514:in `waitFor'
 org/apache/hadoop/hbase/HBaseTestingUtility.java:3576:in 
 `waitLabelAvailable'
 ./src/test/ruby/hbase/visibility_labels_admin_test.rb:73:in 
 `test_The_get/put_methods_should_work_for_data_written_with_Visibility'
 org/jruby/RubyProc.java:270:in `call'
 org/jruby/RubyKernel.java:2105:in `send'
 org/jruby/RubyArray.java:1620:in `each'
 org/jruby/RubyArray.java:1620:in `each'
   2) Error:
 test_The_set/clear_methods_should_work_with_authorizations(Hbase::VisibilityLabelsAdminMethodsTest):
 NativeException: junit.framework.AssertionFailedError: Waiting timed out 
 after [10,000] msec
 junit/framework/Assert.java:57:in `fail'
 org/apache/hadoop/hbase/Waiter.java:193:in `waitFor'
 org/apache/hadoop/hbase/Waiter.java:128:in `waitFor'
 org/apache/hadoop/hbase/HBaseTestingUtility.java:3514:in `waitFor'
 org/apache/hadoop/hbase/HBaseTestingUtility.java:3576:in 
 `waitLabelAvailable'
 ./src/test/ruby/hbase/visibility_labels_admin_test.rb:52:in 
 `test_The_set/clear_methods_should_work_with_authorizations'
 org/jruby/RubyProc.java:270:in `call'
 org/jruby/RubyKernel.java:2105:in `send'
 org/jruby/RubyArray.java:1620:in `each'
 org/jruby/RubyArray.java:1620:in `each'
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

1 2 >

1 - 100 of 166 matches

Mail list logo