date:20131003


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

Hadoop QA commented on HBASE-9546:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12606520/HBASE-9546.patch
  against trunk revision .

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

{color:green}+1 tests included{color}.  The patch appears to include 90 new 
or modified tests.

{color:green}+1 hadoop1.0{color}.  The patch compiles against the hadoop 
1.0 profile.

{color:green}+1 hadoop2.0{color}.  The patch compiles against the hadoop 
2.0 profile.

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

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

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) 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:red}-1 site{color}.  The patch appears to cause mvn site goal to 
fail.

{color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7455//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7455//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7455//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7455//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7455//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7455//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7455//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7455//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7455//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7455//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7455//console

This message is automatically generated.

 HFileContext should adopt Builder pattern
 -

 Key: HBASE-9546
 URL: https://issues.apache.org/jira/browse/HBASE-9546
 Project: HBase
  Issue Type: Sub-task
Reporter: Ted Yu
Assignee: ramkrishna.s.vasudevan
 Attachments: HBASE-9546.patch


 HFileContext is used in so many places for HFile v3, HFileContext should use 
 the Builder pattern.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9701) Make SLEEP_TIME in IntegrationTestMTTR configurable


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

Hudson commented on HBASE-9701:
---

FAILURE: Integrated in HBase-TRUNK #4587 (See 
[https://builds.apache.org/job/HBase-TRUNK/4587/])
HBASE-9701 Make SLEEP_TIME in IntegrationTestMTTR configurable (nkeywal: rev 
1528752)
* 
/hbase/trunk/hbase-it/src/test/java/org/apache/hadoop/hbase/mttr/IntegrationTestMTTR.java


 Make SLEEP_TIME in IntegrationTestMTTR configurable
 ---

 Key: HBASE-9701
 URL: https://issues.apache.org/jira/browse/HBASE-9701
 Project: HBase
  Issue Type: Improvement
  Components: test
Affects Versions: 0.98.0, 0.96.1
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
Priority: Minor
 Fix For: 0.98.0, 0.96.1

 Attachments: HBASE-9701.v1.patch


 This will allow to try to shorten the testing time.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9681) Basic codec negotiation

2013-10-03 Thread Andrew Purtell (JIRA)

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

Andrew Purtell commented on HBASE-9681:
---

bq. And the header of which can be forcefully made negative and the
client/server understands the new response/request if the header size is
negative?

Sounds like a nasty hack Ram.

So a 0.96 client won't barf on this new request/response message you propose?
How is that a different approach than my OP on this issue? Perhaps you can put
up a design doc explaining.

Basic codec negotiation
---

Key: HBASE-9681
URL: https://issues.apache.org/jira/browse/HBASE-9681
Project: HBase
Issue Type: Sub-task
Affects Versions: 0.98.0
Reporter: Andrew Purtell

Basic codec negotiation:
There should be a default codec used for cell encoding over the RPC
connection. This should be configurable in the site file.
The client can optionally send a message, a manufactured call that would
otherwise be invalid in some way, to the server asking for a list of
supported cell codecs. An older server should simply send back an error
because the request is invalid except to servers supporting this feature. A
server supporting this feature should send back the requested information or
an error indication if something went wrong.
The client can optionally send a message, a manufactured call that would
otherwise be invalid in some way, to the server asking for it to use a given
codec for all further communication. Otherwise the server will continue to
use the default codec. The server will send back a call response
acknowledging the change or an error indication if the request cannot be
honored.
Server configuration should support mappings from one codec type to another.
We need to handle the case where the server has a codec available that
extends the requested type but overrides some behavior in the base class, and
this is what should be used in lieu of the base type. It must also be
possible to choose an alternate default codec which stands in for the default
codec, is compatible with client expectations, but changes the server side
behavior as needed in the absence of negotiation.

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9681) Basic codec negotiation

2013-10-03 Thread ramkrishna.s.vasudevan (JIRA)

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

ramkrishna.s.vasudevan commented on HBASE-9681:
---

Sure..
bq.Sounds like a nasty hack Ram.
I have tried removing this way of getting the reponse back and forth. Will
post a design doc sooner.
I am working on a cleaner way of doing rather than making the header negative.

Basic codec negotiation
---

Key: HBASE-9681
URL: https://issues.apache.org/jira/browse/HBASE-9681
Project: HBase
Issue Type: Sub-task
Affects Versions: 0.98.0
Reporter: Andrew Purtell

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9701) Make SLEEP_TIME in IntegrationTestMTTR configurable


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

Hudson commented on HBASE-9701:
---

SUCCESS: Integrated in hbase-0.96 #119 (See 
[https://builds.apache.org/job/hbase-0.96/119/])
HBASE-9701 Make SLEEP_TIME in IntegrationTestMTTR configurable (nkeywal: rev 
1528753)
* 
/hbase/branches/0.96/hbase-it/src/test/java/org/apache/hadoop/hbase/mttr/IntegrationTestMTTR.java


 Make SLEEP_TIME in IntegrationTestMTTR configurable
 ---

 Key: HBASE-9701
 URL: https://issues.apache.org/jira/browse/HBASE-9701
 Project: HBase
  Issue Type: Improvement
  Components: test
Affects Versions: 0.98.0, 0.96.1
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
Priority: Minor
 Fix For: 0.98.0, 0.96.1

 Attachments: HBASE-9701.v1.patch


 This will allow to try to shorten the testing time.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9701) Make SLEEP_TIME in IntegrationTestMTTR configurable


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

Hudson commented on HBASE-9701:
---

SUCCESS: Integrated in hbase-0.96-hadoop2 #72 (See 
[https://builds.apache.org/job/hbase-0.96-hadoop2/72/])
HBASE-9701 Make SLEEP_TIME in IntegrationTestMTTR configurable (nkeywal: rev 
1528753)
* 
/hbase/branches/0.96/hbase-it/src/test/java/org/apache/hadoop/hbase/mttr/IntegrationTestMTTR.java


 Make SLEEP_TIME in IntegrationTestMTTR configurable
 ---

 Key: HBASE-9701
 URL: https://issues.apache.org/jira/browse/HBASE-9701
 Project: HBase
  Issue Type: Improvement
  Components: test
Affects Versions: 0.98.0, 0.96.1
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
Priority: Minor
 Fix For: 0.98.0, 0.96.1

 Attachments: HBASE-9701.v1.patch


 This will allow to try to shorten the testing time.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9701) Make SLEEP_TIME in IntegrationTestMTTR configurable


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

Hudson commented on HBASE-9701:
---

SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #775 (See 
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/775/])
HBASE-9701 Make SLEEP_TIME in IntegrationTestMTTR configurable (nkeywal: rev 
1528752)
* 
/hbase/trunk/hbase-it/src/test/java/org/apache/hadoop/hbase/mttr/IntegrationTestMTTR.java


 Make SLEEP_TIME in IntegrationTestMTTR configurable
 ---

 Key: HBASE-9701
 URL: https://issues.apache.org/jira/browse/HBASE-9701
 Project: HBase
  Issue Type: Improvement
  Components: test
Affects Versions: 0.98.0, 0.96.1
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
Priority: Minor
 Fix For: 0.98.0, 0.96.1

 Attachments: HBASE-9701.v1.patch


 This will allow to try to shorten the testing time.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9612) Ability to batch edits destined to different regions


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

stack commented on HBASE-9612:
--

[~tsuna] If we did not have the batch call, yeah, we could just send edits. We 
could leave aside one pb layer (There'd be no need of the Action Get/Mutation 
union).

[~liochon] We should be able to add this later as another option on the Action 
union (a CheckAndPutMutation or extend Mutation with content of Condition).

 Ability to batch edits destined to different regions
 

 Key: HBASE-9612
 URL: https://issues.apache.org/jira/browse/HBASE-9612
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.0, 0.95.1, 0.95.2, 0.96.0
Reporter: Benoit Sigoure
Assignee: stack
Priority: Critical
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-fix-packaging-by-region-in-MultiServerCallable.patch, 9612.096.v5.txt, 
 9612revert.txt, 9612v2.txt, 9612v3.txt, 9612v4.txt, 9612v5.txt, 9612v5.txt, 
 9612v5.txt, 9612v7.txt, 9612v8.096.txt, 9612v8.txt, 9612v9.txt, 9612v9.txt, 
 9612.wip.txt


 The old (pre-PB) multi and multiPut RPCs allowed one to batch edits 
 destined to different regions.  Seems like we've lost this ability after the 
 switch to protobufs.
 The {{MultiRequest}} only contains one {{RegionSpecifier}}, and a list of 
 {{MultiAction}}.  The {{MultiAction}} message is contains either a single 
 {{MutationProto}} or a {{Get}} (but not both – so its name is misleading as 
 there is nothing multi about it).  Also it seems redundant with 
 {{MultiGetRequest}}, I'm not sure what's the point of supporting {{Get}} in 
 {{MultiAction}}.
 I propose that we change {{MultiRequest}} to be a just a list of 
 {{MultiAction}}, and {{MultiAction}} will contain the {{RegionSpecifier}}, 
 the {{bool atomic}} and a list of {{MutationProto}}.  This would be a 
 non-backward compatible protobuf change.
 If we want we can support mixing edits and reads, in which case we'd also add 
 a list of {{Get}} in {{MultiAction}}, and we'd have support having both that 
 list and the list of {{MutationProto}} set at the same time.  But this is a 
 bonus and can be done later (in a backward compatible manner, hence no need 
 to rush on this one).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (HBASE-9705) The HConnectionImplementation's constructor does not need throw ZooKeeperConnectionException

2013-10-03 Thread dereek.deng (JIRA)

dereek.deng created HBASE-9705:
--

 Summary: The HConnectionImplementation's constructor does not need 
throw ZooKeeperConnectionException
 Key: HBASE-9705
 URL: https://issues.apache.org/jira/browse/HBASE-9705
 Project: HBase
  Issue Type: Improvement
  Components: Client
Reporter: dereek.deng
Priority: Minor


As the summary said, the HConnectionImplementation's constructor does not need 
throw ZooKeeperConnectionException, because it does not connection to ZK.
And, if delete it belong, ZooKeeperConnectionException does not need in 
createConnection(), getConnection(), getSpiedConnection() and 
HConnectionRaceTester() 's constructor.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9681) Basic codec negotiation

2013-10-03 Thread Elliott Clark (JIRA)

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

Elliott Clark commented on HBASE-9681:
--

bq.The client can optionally send a message, a manufactured call that would
otherwise be invalid in some way, to the server asking for a list of supported
cell codecs.

That sounds like a lot of round trips. Can we have the client send a
preference ordered list of codec it wants.

Basic codec negotiation
---

Key: HBASE-9681
URL: https://issues.apache.org/jira/browse/HBASE-9681
Project: HBase
Issue Type: Sub-task
Affects Versions: 0.98.0
Reporter: Andrew Purtell

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-7404) Bucket Cache:A solution about CMS,Heap Fragment and Big Cache on HBASE


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

Lars Hofhansl commented on HBASE-7404:
--

Thanks [~zjushch]. I do understand the aim of the patch. :)
This does replace the LruCache when you enable it, right? (for all but meta 
blocks)
I.e. you cannot use the BucketCache for some data blocks and the LruCache for 
some other data blocks. That is the reason why this cannot be generally enabled.

If the bucket cache was in addition to the LruCache as a cold cache or L2 
cache then it would be a different story (for example, say you have a machine 
with 128 or 256gb or ram, currently HBase cannot make use of that except for as 
OS buffer cache, if some of this memory could be given to the bucket cache 
while the LruCache would still be used as before we could always enable this). 
That appears to be the aim of HBASE-8894.


 Bucket Cache:A solution about CMS,Heap Fragment and Big Cache on HBASE
 --

 Key: HBASE-7404
 URL: https://issues.apache.org/jira/browse/HBASE-7404
 Project: HBase
  Issue Type: New Feature
Affects Versions: 0.94.3
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.95.0

 Attachments: 7404-0.94-fixed-lines.txt, 7404-trunk-v10.patch, 
 7404-trunk-v11.patch, 7404-trunk-v12.patch, 7404-trunk-v13.patch, 
 7404-trunk-v13.txt, 7404-trunk-v14.patch, BucketCache.pdf, 
 hbase-7404-94v2.patch, HBASE-7404-backport-0.94.patch, 
 hbase-7404-trunkv2.patch, hbase-7404-trunkv9.patch, Introduction of Bucket 
 Cache.pdf


 First, thanks @neil from Fusion-IO share the source code.
 Usage:
 1.Use bucket cache as main memory cache, configured as the following:
 –hbase.bucketcache.ioengine heap
 –hbase.bucketcache.size 0.4 (size for bucket cache, 0.4 is a percentage of 
 max heap size)
 2.Use bucket cache as a secondary cache, configured as the following:
 –hbase.bucketcache.ioengine file:/disk1/hbase/cache.data(The file path 
 where to store the block data)
 –hbase.bucketcache.size 1024 (size for bucket cache, unit is MB, so 1024 
 means 1GB)
 –hbase.bucketcache.combinedcache.enabled false (default value being true)
 See more configurations from org.apache.hadoop.hbase.io.hfile.CacheConfig and 
 org.apache.hadoop.hbase.io.hfile.bucket.BucketCache
 What's Bucket Cache? 
 It could greatly decrease CMS and heap fragment by GC
 It support a large cache space for High Read Performance by using high speed 
 disk like Fusion-io
 1.An implementation of block cache like LruBlockCache
 2.Self manage blocks' storage position through Bucket Allocator
 3.The cached blocks could be stored in the memory or file system
 4.Bucket Cache could be used as a mainly block cache(see CombinedBlockCache), 
 combined with LruBlockCache to decrease CMS and fragment by GC.
 5.BucketCache also could be used as a secondary cache(e.g. using Fusionio to 
 store block) to enlarge cache space
 How about SlabCache?
 We have studied and test SlabCache first, but the result is bad, because:
 1.SlabCache use SingleSizeCache, its use ratio of memory is low because kinds 
 of block size, especially using DataBlockEncoding
 2.SlabCache is uesd in DoubleBlockCache, block is cached both in SlabCache 
 and LruBlockCache, put the block to LruBlockCache again if hit in SlabCache , 
 it causes CMS and heap fragment don't get any better
 3.Direct heap performance is not good as heap, and maybe cause OOM, so we 
 recommend using heap engine 
 See more in the attachment and in the patch



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-8894) Forward port compressed l2 cache from 0.89fb


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

Lars Hofhansl commented on HBASE-8894:
--

Is my characterization of the design above correct? I'd add that then we'd 
triple cache the data (it's loaded into the OS cache first, then into the L2 
cache, from there into the LruCache).


 Forward port compressed l2 cache from 0.89fb
 

 Key: HBASE-8894
 URL: https://issues.apache.org/jira/browse/HBASE-8894
 Project: HBase
  Issue Type: New Feature
Reporter: stack
Assignee: Liang Xie
Priority: Critical
 Fix For: 0.98.0


 Forward port Alex's improvement on hbase-7407 from 0.89-fb branch:
 {code}
   1 r1492797 | liyin | 2013-06-13 11:18:20 -0700 (Thu, 13 Jun 2013) | 43 lines
   2
   3 [master] Implements a secondary compressed cache (L2 cache)
   4
   5 Author: avf
   6
   7 Summary:
   8 This revision implements compressed and encoded second-level cache with 
 off-heap
   9 (and optionally on-heap) storage and a bucket-allocator based on 
 HBASE-7404.
  10
  11 BucketCache from HBASE-7404 is extensively modified to:
  12
  13 * Only handle byte arrays (i.e., no more serialization/deserialization 
 within)
  14 * Remove persistence support for the time being
  15 * Keep an  index of hfilename to blocks for efficient eviction on close
  16
  17 A new interface (L2Cache) is introduced in order to separate it from the 
 current
  18 implementation. The L2 cache is then integrated into the classes that 
 handle
  19 reading from and writing to HFiles to allow cache-on-write as well as
  20 cache-on-read. Metrics for the L2 cache are integrated into 
 RegionServerMetrics
  21 much in the same fashion as metrics for the existing (L2) BlockCache.
  22
  23 Additionally, CacheConfig class is re-refactored to configure the L2 
 cache,
  24 replace multile constructors with a Builder, as well as replace static 
 methods
  25 for instantiating the caches with abstract factories (with singleton
  26 implementations for both the existing LruBlockCache and the newly 
 introduced
  27 BucketCache based L2 cache)
  28
  29 Test Plan:
  30 1) Additional unit tests
  31 2) Stress test on a single devserver
  32 3) Test on a single-node in shadow cluster
  33 4) Test on a whole shadow cluster
  34
  35 Revert Plan:
  36
  37 Reviewers: liyintang, aaiyer, rshroff, manukranthk, adela
  38
  39 Reviewed By: liyintang
  40
  41 CC: gqchen, hbase-eng@
  42
  43 Differential Revision: https://phabricator.fb.com/D837264
  44
  45 Task ID: 2325295
  7 
   6 r1492340 | liyin | 2013-06-12 11:36:03 -0700 (Wed, 12 Jun 2013) | 21 lines
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-4811) Support reverse Scan


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

Lars Hofhansl commented on HBASE-4811:
--

Sorry, should have stated that I was referring seekToNextRow and 
seekAsDirection as being synchronized, but calling a synchronized method in the 
forward case (For the record: I do not think that is a problem)

My test is indeed CPU bound correct. I skimmed over the patch, and it is not 
immediately where the extra CPU comes from (except for the cases I mentioned). 
Do you have a specific part of the code where you think it adds CPU cost to 
forward scanning, [~zjushch]?
(It's fine if reverse scanning is slower, but forward scanning should not be 
impacted)

 Support reverse Scan
 

 Key: HBASE-4811
 URL: https://issues.apache.org/jira/browse/HBASE-4811
 Project: HBase
  Issue Type: New Feature
  Components: Client
Affects Versions: 0.20.6, 0.94.7
Reporter: John Carrino
Assignee: chunhui shen
 Fix For: 0.98.0

 Attachments: 4811-0.94-v3.txt, 4811-trunk-v10.txt, 
 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt, hbase-4811-0.94 
 v21.patch, HBase-4811-0.94-v2.txt, hbase-4811-trunkv11.patch, 
 hbase-4811-trunkv12.patch, hbase-4811-trunkv13.patch, 
 hbase-4811-trunkv14.patch, hbase-4811-trunkv15.patch, 
 hbase-4811-trunkv16.patch, hbase-4811-trunkv17.patch, 
 hbase-4811-trunkv18.patch, hbase-4811-trunkv19.patch, 
 hbase-4811-trunkv1.patch, hbase-4811-trunkv20.patch, 
 hbase-4811-trunkv21.patch, hbase-4811-trunkv4.patch, 
 hbase-4811-trunkv6.patch, hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, 
 hbase-4811-trunkv9.patch


 Reversed scan means scan the rows backward. 
 And StartRow bigger than StopRow in a reversed scan.
 For example, for the following rows:
 aaa/c1:q1/value1
 aaa/c1:q2/value2
 bbb/c1:q1/value1
 bbb/c1:q2/value2
 ccc/c1:q1/value1
 ccc/c1:q2/value2
 ddd/c1:q1/value1
 ddd/c1:q2/value2
 eee/c1:q1/value1
 eee/c1:q2/value2
 you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
 Scan scan = new Scan();
 scan.setStartRow('ddd');
 scan.setStopRow('bbb');
 scan.setReversed(true);
 for(Result result:htable.getScanner(scan)){
  System.out.println(result);
 }
 Aslo you could do the reversed scan with shell like this:
 hbase scan 'table',{REVERSED = true,STARTROW='ddd', STOPROW='bbb'}
 And the output is:
 ddd/c1:q1/value1
 ddd/c1:q2/value2
 ccc/c1:q1/value1
 ccc/c1:q2/value2
 NOTE: when setting reversed as true for a client scan, you must set the start 
 row, else will throw exception. Through {@link 
 Scan#createBiggestByteArray(int)},you could get a big enough byte array as 
 the start row
 All the documentation I find about HBase says that if you want forward and 
 reverse scans you should just build 2 tables and one be ascending and one 
 descending.  Is there a fundamental reason that HBase only supports forward 
 Scan?  It seems like a lot of extra space overhead and coding overhead (to 
 keep them in sync) to support 2 tables.  
 I am assuming this has been discussed before, but I can't find the 
 discussions anywhere about it or why it would be infeasible.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9546) HFileContext should adopt Builder pattern


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

Ted Yu commented on HBASE-9546:
---

For HFileDataBlockEncoderImpl.java :
{code}
+  private HFileBlockEncodingContext createInCacheEncodingContext(HFileContext 
fileContext) {
+HFileContext newContext = new HFileContextBuilder()
+  .withBlockSize(fileContext.getBlocksize())
+  
.withBytesPerCheckSum(fileContext.getBytesPerChecksum())
+  .withChecksumType(fileContext.getChecksumType())
+  
.withCompressionAlgo(fileContext.getCompression())
+  
.withDataBlockEncodingInCache(fileContext.getEncodingInCache())
+  
.withDataBlockEncodingOnDisk(fileContext.getEncodingOnDisk())
+  
.withHBaseCheckSum(fileContext.shouldUseHBaseChecksum())
+  
.withCompressTags(fileContext.shouldCompressTags())
+  
.withIncludesMvcc(fileContext.shouldIncludeMvcc())
+  
.withIncludesTags(fileContext.shouldIncludeTags()).build();
{code}
Would HFileContext copy constructor be more suitable in the above case ? More 
fields may be added to HFileContext in the future.

 HFileContext should adopt Builder pattern
 -

 Key: HBASE-9546
 URL: https://issues.apache.org/jira/browse/HBASE-9546
 Project: HBase
  Issue Type: Sub-task
Reporter: Ted Yu
Assignee: ramkrishna.s.vasudevan
 Attachments: HBASE-9546.patch


 HFileContext is used in so many places for HFile v3, HFileContext should use 
 the Builder pattern.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9705) The HConnectionImplementation's constructor does not need throw ZooKeeperConnectionException

2013-10-03 Thread Jean-Marc Spaggiari (JIRA)


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

Jean-Marc Spaggiari commented on HBASE-9705:


Hi Derek,

are you going to provide a patch for that?

 The HConnectionImplementation's constructor does not need throw 
 ZooKeeperConnectionException
 

 Key: HBASE-9705
 URL: https://issues.apache.org/jira/browse/HBASE-9705
 Project: HBase
  Issue Type: Improvement
  Components: Client
Reporter: dereek.deng
Priority: Minor
   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 As the summary said, the HConnectionImplementation's constructor does not 
 need throw ZooKeeperConnectionException, because it does not connection to ZK.
 And, if delete it belong, ZooKeeperConnectionException does not need in 
 createConnection(), getConnection(), getSpiedConnection() and 
 HConnectionRaceTester() 's constructor.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9693) Fix javadoc warnings

2013-10-03 Thread Himanshu Vashishtha (JIRA)


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

Himanshu Vashishtha commented on HBASE-9693:


+1
minor nit: fix typo on commit: 
which may not be what ou want).

 Fix javadoc warnings
 

 Key: HBASE-9693
 URL: https://issues.apache.org/jira/browse/HBASE-9693
 Project: HBase
  Issue Type: Task
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Attachments: trunk-9693.patch


 There are not many javadoc warnings.  We can fix them all.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (HBASE-9706) Improve detection of secure ZooKeeper

Eric Yang created HBASE-9706:


 Summary: Improve detection of secure ZooKeeper
 Key: HBASE-9706
 URL: https://issues.apache.org/jira/browse/HBASE-9706
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.95.0, 0.94.4
 Environment: Java 6, RHEL, HBase 0.94.9
Reporter: Eric Yang


HBase client code assumes ZooKeeper is secured, as long as there is a 
java.security.auth.login.config property being set.  When HBase client is 
embedded in other java program with other security configuration, it can 
produce wrong assumption that ZooKeeper is secured.  Ideally, isSecureZooKeeper 
method should detect Jaas configuration specifically for ZooKeeper to ensure 
that client program don't have a false positive detection.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9706) Improve detection of secure ZooKeeper


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

Eric Yang updated HBASE-9706:
-

Description: HBase client code assumes ZooKeeper is secured, as long as 
there is a java.security.auth.login.config property being set.  When HBase 
client is embedded in other java program with other security configuration, it 
can produce wrong assumption that ZooKeeper is secured.  Ideally, 
isSecureZooKeeper method should detect Jaas configuration specifically for 
ZooKeeper to ensure that client program doesn't have a false positive 
detection.  (was: HBase client code assumes ZooKeeper is secured, as long as 
there is a java.security.auth.login.config property being set.  When HBase 
client is embedded in other java program with other security configuration, it 
can produce wrong assumption that ZooKeeper is secured.  Ideally, 
isSecureZooKeeper method should detect Jaas configuration specifically for 
ZooKeeper to ensure that client program don't have a false positive detection.)

 Improve detection of secure ZooKeeper
 -

 Key: HBASE-9706
 URL: https://issues.apache.org/jira/browse/HBASE-9706
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.94.4, 0.95.0
 Environment: Java 6, RHEL, HBase 0.94.9
Reporter: Eric Yang

 HBase client code assumes ZooKeeper is secured, as long as there is a 
 java.security.auth.login.config property being set.  When HBase client is 
 embedded in other java program with other security configuration, it can 
 produce wrong assumption that ZooKeeper is secured.  Ideally, 
 isSecureZooKeeper method should detect Jaas configuration specifically for 
 ZooKeeper to ensure that client program doesn't have a false positive 
 detection.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9693) Fix javadoc warnings


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

Jonathan Hsieh commented on HBASE-9693:
---

+!

 Fix javadoc warnings
 

 Key: HBASE-9693
 URL: https://issues.apache.org/jira/browse/HBASE-9693
 Project: HBase
  Issue Type: Task
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Attachments: trunk-9693.patch


 There are not many javadoc warnings.  We can fix them all.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (HBASE-9693) Fix javadoc warnings


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

Jonathan Hsieh edited comment on HBASE-9693 at 10/3/13 5:04 PM:


+1


was (Author: jmhsieh):
+!

 Fix javadoc warnings
 

 Key: HBASE-9693
 URL: https://issues.apache.org/jira/browse/HBASE-9693
 Project: HBase
  Issue Type: Task
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Attachments: trunk-9693.patch


 There are not many javadoc warnings.  We can fix them all.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9694) HBaseTestingUtility.createTable infinite loop


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

Jonathan Hsieh commented on HBASE-9694:
---

How about removing it instead then?

 HBaseTestingUtility.createTable infinite loop
 -

 Key: HBASE-9694
 URL: https://issues.apache.org/jira/browse/HBASE-9694
 Project: HBase
  Issue Type: Bug
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
 Attachments: HBASE-9694-v0-trunk.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 We need to fix this.
 {code}
   public HTable createTable(String tableName, String[] families)
   throws IOException {
 return createTable(tableName, families);
   }
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9612) Ability to batch edits destined to different regions


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

stack updated HBASE-9612:
-

Attachment: 9612v10.txt

The TestFromClientSide was legit failure.

Fixed by disallowing RowMutations in multi -- it a curtailment of functionality 
compared to 0.94 but it unnecessarily complicates the multi implementation (and 
in 0.94 it is done messily anyways).  Only one call in all tests makes use of 
it and it should be doing rowMutation anyways.  Will release note this.

Lets see how this patch does.

 Ability to batch edits destined to different regions
 

 Key: HBASE-9612
 URL: https://issues.apache.org/jira/browse/HBASE-9612
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.0, 0.95.1, 0.95.2, 0.96.0
Reporter: Benoit Sigoure
Assignee: stack
Priority: Critical
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-fix-packaging-by-region-in-MultiServerCallable.patch, 9612.096.v5.txt, 
 9612revert.txt, 9612v10.txt, 9612v2.txt, 9612v3.txt, 9612v4.txt, 9612v5.txt, 
 9612v5.txt, 9612v5.txt, 9612v7.txt, 9612v8.096.txt, 9612v8.txt, 9612v9.txt, 
 9612v9.txt, 9612.wip.txt


 The old (pre-PB) multi and multiPut RPCs allowed one to batch edits 
 destined to different regions.  Seems like we've lost this ability after the 
 switch to protobufs.
 The {{MultiRequest}} only contains one {{RegionSpecifier}}, and a list of 
 {{MultiAction}}.  The {{MultiAction}} message is contains either a single 
 {{MutationProto}} or a {{Get}} (but not both – so its name is misleading as 
 there is nothing multi about it).  Also it seems redundant with 
 {{MultiGetRequest}}, I'm not sure what's the point of supporting {{Get}} in 
 {{MultiAction}}.
 I propose that we change {{MultiRequest}} to be a just a list of 
 {{MultiAction}}, and {{MultiAction}} will contain the {{RegionSpecifier}}, 
 the {{bool atomic}} and a list of {{MutationProto}}.  This would be a 
 non-backward compatible protobuf change.
 If we want we can support mixing edits and reads, in which case we'd also add 
 a list of {{Get}} in {{MultiAction}}, and we'd have support having both that 
 list and the list of {{MutationProto}} set at the same time.  But this is a 
 bonus and can be done later (in a backward compatible manner, hence no need 
 to rush on this one).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9695) Some never used local variables cleanup.


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

Jonathan Hsieh commented on HBASE-9695:
---

I'd suggest removing, or adding an assert test to it. 

 Some never used local variables cleanup.
 

 Key: HBASE-9695
 URL: https://issues.apache.org/jira/browse/HBASE-9695
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.98.0, 0.96.1
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
 Attachments: HBASE-9695-v0-trunk.patch


 There is few local variables defined that we can clean-up.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9612) Ability to batch edits destined to different regions


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

Hadoop QA commented on HBASE-9612:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12606602/9612v10.txt
  against trunk revision .

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

{color:green}+1 tests included{color}.  The patch appears to include 18 new 
or modified tests.

{color:red}-1 hadoop1.0{color}.  The patch failed to compile against the 
hadoop 1.0 profile.

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

This message is automatically generated.

 Ability to batch edits destined to different regions
 

 Key: HBASE-9612
 URL: https://issues.apache.org/jira/browse/HBASE-9612
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.0, 0.95.1, 0.95.2, 0.96.0
Reporter: Benoit Sigoure
Assignee: stack
Priority: Critical
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-fix-packaging-by-region-in-MultiServerCallable.patch, 9612.096.v5.txt, 
 9612revert.txt, 9612v10.txt, 9612v2.txt, 9612v3.txt, 9612v4.txt, 9612v5.txt, 
 9612v5.txt, 9612v5.txt, 9612v7.txt, 9612v8.096.txt, 9612v8.txt, 9612v9.txt, 
 9612v9.txt, 9612.wip.txt


 The old (pre-PB) multi and multiPut RPCs allowed one to batch edits 
 destined to different regions.  Seems like we've lost this ability after the 
 switch to protobufs.
 The {{MultiRequest}} only contains one {{RegionSpecifier}}, and a list of 
 {{MultiAction}}.  The {{MultiAction}} message is contains either a single 
 {{MutationProto}} or a {{Get}} (but not both – so its name is misleading as 
 there is nothing multi about it).  Also it seems redundant with 
 {{MultiGetRequest}}, I'm not sure what's the point of supporting {{Get}} in 
 {{MultiAction}}.
 I propose that we change {{MultiRequest}} to be a just a list of 
 {{MultiAction}}, and {{MultiAction}} will contain the {{RegionSpecifier}}, 
 the {{bool atomic}} and a list of {{MutationProto}}.  This would be a 
 non-backward compatible protobuf change.
 If we want we can support mixing edits and reads, in which case we'd also add 
 a list of {{Get}} in {{MultiAction}}, and we'd have support having both that 
 list and the list of {{MutationProto}} set at the same time.  But this is a 
 bonus and can be done later (in a backward compatible manner, hence no need 
 to rush on this one).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9693) Fix javadoc warnings


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

Jimmy Xiang commented on HBASE-9693:


Thanks Jon too.

 Fix javadoc warnings
 

 Key: HBASE-9693
 URL: https://issues.apache.org/jira/browse/HBASE-9693
 Project: HBase
  Issue Type: Task
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Fix For: 0.98.0, 0.96.0

 Attachments: trunk-9693.patch


 There are not many javadoc warnings.  We can fix them all.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9693) Fix javadoc warnings


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

Jimmy Xiang updated HBASE-9693:
---

   Resolution: Fixed
Fix Version/s: 0.96.0
   0.98.0
 Hadoop Flags: Reviewed
   Status: Resolved  (was: Patch Available)

Integrated into trunk and 0.96.  Thanks Himanshu for the review.

 Fix javadoc warnings
 

 Key: HBASE-9693
 URL: https://issues.apache.org/jira/browse/HBASE-9693
 Project: HBase
  Issue Type: Task
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Fix For: 0.98.0, 0.96.0

 Attachments: trunk-9693.patch


 There are not many javadoc warnings.  We can fix them all.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9696) Master recovery ignores online merge znode


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

Jimmy Xiang updated HBASE-9696:
---

Attachment: trunk-9696.patch

Attached a patch that contains the following changes:

1. introduced two new states for region to be created at merging/splitting.  
don't have good names for them.
2. changed the payload of RegionTransition for merging/splitting, so that the 
new region info is also passed to master when the process started. Therefore, 
we can simplify the processing of these events, and make sure the new region 
can't be moved after the process is done, so that they can be closed properly 
when moving.
3. handled merging region at master recovery properly.
4. added test for 3.
5. some code consolidation with Split/MergeRegionHandler


 Master recovery ignores online merge znode
 --

 Key: HBASE-9696
 URL: https://issues.apache.org/jira/browse/HBASE-9696
 Project: HBase
  Issue Type: Bug
  Components: master, Region Assignment
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
 Attachments: trunk-9696.patch


 The online merge znode uses the new region to be created.  When master 
 restarts, the new region is still unknown if the merging is not completed. 
 Therefore the znode is ignored, which should not.  That means the two merging 
 regions could be moved around.  This could cause some data loss if we are not 
 luck.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9686) More temporary test files are being left in /tmp/hbase-user


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

Jonathan Hsieh commented on HBASE-9686:
---

I'm going to commit v2 later today.

 More temporary test files are being left in /tmp/hbase-user
 -

 Key: HBASE-9686
 URL: https://issues.apache.org/jira/browse/HBASE-9686
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9686.patch, hbase-9686.v2.patch


 There is currently about 160MB of stuff being left behind in after a unit 
 test run in our jenkins setup.
 Table names left behind indicate that it is due to these classes.
 TestCompaction
 Either TestForceCacheImporatntBlocks or TestScannerSelectionUingTTL or 
 TestScannerSelectionUsingKeyRange
 TestHRegion



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9696) Master recovery ignores online merge znode


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

Jimmy Xiang updated HBASE-9696:
---

Status: Patch Available  (was: Open)

 Master recovery ignores online merge znode
 --

 Key: HBASE-9696
 URL: https://issues.apache.org/jira/browse/HBASE-9696
 Project: HBase
  Issue Type: Bug
  Components: master, Region Assignment
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
 Attachments: trunk-9696.patch


 The online merge znode uses the new region to be created.  When master 
 restarts, the new region is still unknown if the merging is not completed. 
 Therefore the znode is ignored, which should not.  That means the two merging 
 regions could be moved around.  This could cause some data loss if we are not 
 luck.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (HBASE-9707) [ref guide] make the client configurations easier to find

2013-10-03 Thread Jean-Daniel Cryans (JIRA)

Jean-Daniel Cryans created HBASE-9707:
-

 Summary: [ref guide] make the client configurations easier to find
 Key: HBASE-9707
 URL: https://issues.apache.org/jira/browse/HBASE-9707
 Project: HBase
  Issue Type: Improvement
Reporter: Jean-Daniel Cryans
Priority: Minor


From irc:

{quote}
10:15  mgmuscari may i suggest a note in the quickstart guide
10:16  mgmuscari something like For information on configuring your HBase 
client to connect to a remote master, see here
...
10:19  mgmuscari my particular use case here was
10:19  mgmuscari we have a hadoop cluster already
10:19  mgmuscari and someone installed hbase on it
10:20  mgmuscari so my goal was to immediately connect to the distributed 
cluster after downloading the hbase distributable
10:20  mgmuscari it didn't occur to me that chapter 2 would be relevant to 
configuring the client
{quote}

Currently the client configurations is placed after we list all the 
hbase-site.xml possible configurations like some second class citizen. Maybe it 
would be better to move it after 2.2.3. Running and Confirming Your 
Installation since that's the next logical step.

Chapter 4, The Apache HBase Shell, should also link to the client configs 
since you might want to run it remotely.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9696) Master recovery ignores online merge znode


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

Jimmy Xiang commented on HBASE-9696:


The patch is on RB: https://reviews.apache.org/r/14470/

 Master recovery ignores online merge znode
 --

 Key: HBASE-9696
 URL: https://issues.apache.org/jira/browse/HBASE-9696
 Project: HBase
  Issue Type: Bug
  Components: master, Region Assignment
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
 Attachments: trunk-9696.patch


 The online merge znode uses the new region to be created.  When master 
 restarts, the new region is still unknown if the merging is not completed. 
 Therefore the znode is ignored, which should not.  That means the two merging 
 regions could be moved around.  This could cause some data loss if we are not 
 luck.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (HBASE-9708) Improve Snapshot Name Error Message

2013-10-03 Thread Jesse Anderson (JIRA)

Jesse Anderson created HBASE-9708:
-

 Summary: Improve Snapshot Name Error Message
 Key: HBASE-9708
 URL: https://issues.apache.org/jira/browse/HBASE-9708
 Project: HBase
  Issue Type: Bug
  Components: snapshots
Affects Versions: 0.94.2
Reporter: Jesse Anderson
Priority: Minor


The output for snapshots when you enter an invalid snapshot name talks about 
User-space table names instead of Snapshot names. The error message should 
say Snapshot names can only contain

Here is an example of the output:

{noformat}
hbase(main):001:0 snapshot 'user', 'asdf asdf'

ERROR: java.lang.IllegalArgumentException: Illegal character 32 at 4. 
User-space table names can only contain 'word characters': i.e. [a-zA-Z_0-9-.]: 
asdf asdf

Here is some help for this command:
Take a snapshot of specified table. Examples:

  hbase snapshot 'sourceTable', 'snapshotName'
{noformat}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9694) HBaseTestingUtility.createTable infinite loop

2013-10-03 Thread Jean-Marc Spaggiari (JIRA)


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

Jean-Marc Spaggiari commented on HBASE-9694:


I'm fine with this option too. I kept it because that provide an example, and 
does not really cause any overhead. Compiler will just remove it if still not 
used.

Just let me know what's the final choice and I will update the patch if 
required.

 HBaseTestingUtility.createTable infinite loop
 -

 Key: HBASE-9694
 URL: https://issues.apache.org/jira/browse/HBASE-9694
 Project: HBase
  Issue Type: Bug
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
 Attachments: HBASE-9694-v0-trunk.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 We need to fix this.
 {code}
   public HTable createTable(String tableName, String[] families)
   throws IOException {
 return createTable(tableName, families);
   }
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9696) Master recovery ignores online merge znode


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

Hadoop QA commented on HBASE-9696:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12606604/trunk-9696.patch
  against trunk revision .

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

{color:green}+1 tests included{color}.  The patch appears to include 9 new 
or modified tests.

{color:green}+1 hadoop1.0{color}.  The patch compiles against the hadoop 
1.0 profile.

{color:green}+1 hadoop2.0{color}.  The patch compiles against the hadoop 
2.0 profile.

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

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

{color:red}-1 findbugs{color}.  The patch appears to cause Findbugs 
(version 1.3.9) to fail.

{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:red}-1 site{color}.  The patch appears to cause mvn site goal to 
fail.

{color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7457//testReport/
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7457//console

This message is automatically generated.

 Master recovery ignores online merge znode
 --

 Key: HBASE-9696
 URL: https://issues.apache.org/jira/browse/HBASE-9696
 Project: HBase
  Issue Type: Bug
  Components: master, Region Assignment
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
 Attachments: trunk-9696.patch


 The online merge znode uses the new region to be created.  When master 
 restarts, the new region is still unknown if the merging is not completed. 
 Therefore the znode is ignored, which should not.  That means the two merging 
 regions could be moved around.  This could cause some data loss if we are not 
 luck.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9612) Ability to batch edits destined to different regions


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

stack updated HBASE-9612:
-

Attachment: 9612v11.txt

Missed an import.

 Ability to batch edits destined to different regions
 

 Key: HBASE-9612
 URL: https://issues.apache.org/jira/browse/HBASE-9612
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.0, 0.95.1, 0.95.2, 0.96.0
Reporter: Benoit Sigoure
Assignee: stack
Priority: Critical
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-fix-packaging-by-region-in-MultiServerCallable.patch, 9612.096.v5.txt, 
 9612revert.txt, 9612v10.txt, 9612v11.txt, 9612v2.txt, 9612v3.txt, 9612v4.txt, 
 9612v5.txt, 9612v5.txt, 9612v5.txt, 9612v7.txt, 9612v8.096.txt, 9612v8.txt, 
 9612v9.txt, 9612v9.txt, 9612.wip.txt


 The old (pre-PB) multi and multiPut RPCs allowed one to batch edits 
 destined to different regions.  Seems like we've lost this ability after the 
 switch to protobufs.
 The {{MultiRequest}} only contains one {{RegionSpecifier}}, and a list of 
 {{MultiAction}}.  The {{MultiAction}} message is contains either a single 
 {{MutationProto}} or a {{Get}} (but not both – so its name is misleading as 
 there is nothing multi about it).  Also it seems redundant with 
 {{MultiGetRequest}}, I'm not sure what's the point of supporting {{Get}} in 
 {{MultiAction}}.
 I propose that we change {{MultiRequest}} to be a just a list of 
 {{MultiAction}}, and {{MultiAction}} will contain the {{RegionSpecifier}}, 
 the {{bool atomic}} and a list of {{MutationProto}}.  This would be a 
 non-backward compatible protobuf change.
 If we want we can support mixing edits and reads, in which case we'd also add 
 a list of {{Get}} in {{MultiAction}}, and we'd have support having both that 
 list and the list of {{MutationProto}} set at the same time.  But this is a 
 bonus and can be done later (in a backward compatible manner, hence no need 
 to rush on this one).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-7404) Bucket Cache:A solution about CMS,Heap Fragment and Big Cache on HBASE


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

Lars Hofhansl commented on HBASE-7404:
--

Also... A 60% slowdown is expected here? (I want to make sure I did not 
misconfigure this). Thanks.

 Bucket Cache:A solution about CMS,Heap Fragment and Big Cache on HBASE
 --

 Key: HBASE-7404
 URL: https://issues.apache.org/jira/browse/HBASE-7404
 Project: HBase
  Issue Type: New Feature
Affects Versions: 0.94.3
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.95.0

 Attachments: 7404-0.94-fixed-lines.txt, 7404-trunk-v10.patch, 
 7404-trunk-v11.patch, 7404-trunk-v12.patch, 7404-trunk-v13.patch, 
 7404-trunk-v13.txt, 7404-trunk-v14.patch, BucketCache.pdf, 
 hbase-7404-94v2.patch, HBASE-7404-backport-0.94.patch, 
 hbase-7404-trunkv2.patch, hbase-7404-trunkv9.patch, Introduction of Bucket 
 Cache.pdf


 First, thanks @neil from Fusion-IO share the source code.
 Usage:
 1.Use bucket cache as main memory cache, configured as the following:
 –hbase.bucketcache.ioengine heap
 –hbase.bucketcache.size 0.4 (size for bucket cache, 0.4 is a percentage of 
 max heap size)
 2.Use bucket cache as a secondary cache, configured as the following:
 –hbase.bucketcache.ioengine file:/disk1/hbase/cache.data(The file path 
 where to store the block data)
 –hbase.bucketcache.size 1024 (size for bucket cache, unit is MB, so 1024 
 means 1GB)
 –hbase.bucketcache.combinedcache.enabled false (default value being true)
 See more configurations from org.apache.hadoop.hbase.io.hfile.CacheConfig and 
 org.apache.hadoop.hbase.io.hfile.bucket.BucketCache
 What's Bucket Cache? 
 It could greatly decrease CMS and heap fragment by GC
 It support a large cache space for High Read Performance by using high speed 
 disk like Fusion-io
 1.An implementation of block cache like LruBlockCache
 2.Self manage blocks' storage position through Bucket Allocator
 3.The cached blocks could be stored in the memory or file system
 4.Bucket Cache could be used as a mainly block cache(see CombinedBlockCache), 
 combined with LruBlockCache to decrease CMS and fragment by GC.
 5.BucketCache also could be used as a secondary cache(e.g. using Fusionio to 
 store block) to enlarge cache space
 How about SlabCache?
 We have studied and test SlabCache first, but the result is bad, because:
 1.SlabCache use SingleSizeCache, its use ratio of memory is low because kinds 
 of block size, especially using DataBlockEncoding
 2.SlabCache is uesd in DoubleBlockCache, block is cached both in SlabCache 
 and LruBlockCache, put the block to LruBlockCache again if hit in SlabCache , 
 it causes CMS and heap fragment don't get any better
 3.Direct heap performance is not good as heap, and maybe cause OOM, so we 
 recommend using heap engine 
 See more in the attachment and in the patch



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9694) HBaseTestingUtility.createTable infinite loop


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

Jonathan Hsieh commented on HBASE-9694:
---

let's remove it.  post the patch and Ill commit.

 HBaseTestingUtility.createTable infinite loop
 -

 Key: HBASE-9694
 URL: https://issues.apache.org/jira/browse/HBASE-9694
 Project: HBase
  Issue Type: Bug
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
 Attachments: HBASE-9694-v0-trunk.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 We need to fix this.
 {code}
   public HTable createTable(String tableName, String[] families)
   throws IOException {
 return createTable(tableName, families);
   }
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9686) More temporary test files are being left in /tmp/hbase-user


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

Jonathan Hsieh updated HBASE-9686:
--

Resolution: Fixed
Status: Resolved  (was: Patch Available)

Thanks for the review stack.  Committed to 0.98/trunk and 0.96.  Follow on 
issue for finding the last ones filed as HBASE-9702

 More temporary test files are being left in /tmp/hbase-user
 -

 Key: HBASE-9686
 URL: https://issues.apache.org/jira/browse/HBASE-9686
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9686.patch, hbase-9686.v2.patch


 There is currently about 160MB of stuff being left behind in after a unit 
 test run in our jenkins setup.
 Table names left behind indicate that it is due to these classes.
 TestCompaction
 Either TestForceCacheImporatntBlocks or TestScannerSelectionUingTTL or 
 TestScannerSelectionUsingKeyRange
 TestHRegion



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9693) Fix javadoc warnings


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

Hudson commented on HBASE-9693:
---

SUCCESS: Integrated in hbase-0.96 #120 (See 
[https://builds.apache.org/job/hbase-0.96/120/])
HBASE-9693 Fix javadoc warnings (jxiang: rev 1528944)
* 
/hbase/branches/0.96/hbase-client/src/main/java/org/apache/hadoop/hbase/catalog/MetaReader.java
* 
/hbase/branches/0.96/hbase-common/src/main/java/org/apache/hadoop/hbase/io/compress/Compression.java
* 
/hbase/branches/0.96/hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/executor/EventHandler.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/io/Reference.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFile.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/bucket/BucketCache.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/migration/UpgradeTo96.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/procedure/ProcedureCoordinator.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogSplitter.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/TableAuthManager.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HFileV1Detector.java
* 
/hbase/branches/0.96/hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftServerRunner.java


 Fix javadoc warnings
 

 Key: HBASE-9693
 URL: https://issues.apache.org/jira/browse/HBASE-9693
 Project: HBase
  Issue Type: Task
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Fix For: 0.98.0, 0.96.0

 Attachments: trunk-9693.patch


 There are not many javadoc warnings.  We can fix them all.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9686) More temporary test files are being left in /tmp/hbase-user


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

Jonathan Hsieh updated HBASE-9686:
--

Issue Type: Improvement  (was: Bug)

 More temporary test files are being left in /tmp/hbase-user
 -

 Key: HBASE-9686
 URL: https://issues.apache.org/jira/browse/HBASE-9686
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.96.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9686.patch, hbase-9686.v2.patch


 There is currently about 160MB of stuff being left behind in after a unit 
 test run in our jenkins setup.
 Table names left behind indicate that it is due to these classes.
 TestCompaction
 Either TestForceCacheImporatntBlocks or TestScannerSelectionUingTTL or 
 TestScannerSelectionUsingKeyRange
 TestHRegion



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9693) Fix javadoc warnings


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

Hudson commented on HBASE-9693:
---

FAILURE: Integrated in HBase-TRUNK #4588 (See 
[https://builds.apache.org/job/HBase-TRUNK/4588/])
HBASE-9693 Fix javadoc warnings (jxiang: rev 1528938)
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/catalog/MetaReader.java
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/coprocessor/AggregationClient.java
* /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/Tag.java
* 
/hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/io/compress/Compression.java
* 
/hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/executor/EventHandler.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/Reference.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFile.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/bucket/BucketCache.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/migration/UpgradeTo96.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/procedure/ProcedureCoordinator.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogSplitter.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/TableAuthManager.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HFileV1Detector.java
* 
/hbase/trunk/hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftServerRunner.java


 Fix javadoc warnings
 

 Key: HBASE-9693
 URL: https://issues.apache.org/jira/browse/HBASE-9693
 Project: HBase
  Issue Type: Task
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Fix For: 0.98.0, 0.96.0

 Attachments: trunk-9693.patch


 There are not many javadoc warnings.  We can fix them all.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9698) HBCK does not handle tables with no regions left


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

Enis Soztutar updated HBASE-9698:
-

   Resolution: Fixed
Fix Version/s: (was: 0.96.1)
   0.96.0
 Hadoop Flags: Reviewed
   Status: Resolved  (was: Patch Available)

I've committed v2. Thanks Jon for review. mvn site failure seem to be not 
related. 

 HBCK does not handle tables with no regions left
 

 Key: HBASE-9698
 URL: https://issues.apache.org/jira/browse/HBASE-9698
 Project: HBase
  Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9698_v1.patch, hbase-9698_v2.patch


 hbck does not handle the case where all the regions of a table is gone. To 
 reproduce this: 
 1. create table with one region 
 2. delete the region directory
 3. run hbck --repair, which removes the region from meta as well 
 4. now, the meta won't contain the region, but the table dir in hdfs will be 
 there. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9612) Ability to batch edits destined to different regions


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

Hadoop QA commented on HBASE-9612:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12606613/9612v11.txt
  against trunk revision .

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

{color:green}+1 tests included{color}.  The patch appears to include 18 new 
or modified tests.

{color:green}+1 hadoop1.0{color}.  The patch compiles against the hadoop 
1.0 profile.

{color:green}+1 hadoop2.0{color}.  The patch compiles against the hadoop 
2.0 profile.

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 3 
warning messages.

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

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) 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:red}-1 site{color}.  The patch appears to cause mvn site goal to 
fail.

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
   
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7458//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7458//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7458//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7458//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7458//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7458//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7458//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7458//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7458//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7458//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7458//console

This message is automatically generated.

 Ability to batch edits destined to different regions
 

 Key: HBASE-9612
 URL: https://issues.apache.org/jira/browse/HBASE-9612
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.0, 0.95.1, 0.95.2, 0.96.0
Reporter: Benoit Sigoure
Assignee: stack
Priority: Critical
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-fix-packaging-by-region-in-MultiServerCallable.patch, 9612.096.v5.txt, 
 9612revert.txt, 9612v10.txt, 9612v11.txt, 9612v2.txt, 9612v3.txt, 9612v4.txt, 
 9612v5.txt, 9612v5.txt, 9612v5.txt, 9612v7.txt, 9612v8.096.txt, 9612v8.txt, 
 9612v9.txt, 9612v9.txt, 9612.wip.txt


 The old (pre-PB) multi and multiPut RPCs allowed one to batch edits 
 destined to different regions.  Seems like we've lost this ability after the 
 switch to protobufs.
 The {{MultiRequest}} only contains one {{RegionSpecifier}}, and a list of 
 {{MultiAction}}.  The {{MultiAction}} message is contains either a single 
 {{MutationProto}} or a {{Get}} (but not both – so its name is misleading as 
 there is nothing multi about it).  Also it seems redundant with 
 {{MultiGetRequest}}, I'm not sure what's the point of supporting {{Get}} in 
 {{MultiAction}}.
 I propose that we change {{MultiRequest}} to be a just a list of 
 {{MultiAction}}, and {{MultiAction}} will contain the {{RegionSpecifier}}, 
 the {{bool atomic}} and a list of {{MutationProto}}.  This would be a 
 non-backward compatible protobuf change.
 If we want we can support mixing edits and reads, in which case we'd also add 
 a list of {{Get}} in {{MultiAction}}, and we'd have support having both that 
 list and the list of {{MutationProto}} set at the same time.  But this is a 
 bonus and can be done

[jira] [Commented] (HBASE-9687) ClassNotFoundException is thrown when ExportSnapshot runs against hadoop cluster where HBase is not installed on the same node as resourcemanager


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

Ted Yu commented on HBASE-9687:
---

Once MAPREDUCE-5558 gets integrated to the next hadoop 2 release, we can use 
patch v1 which would make snapshot export work.

 ClassNotFoundException is thrown when ExportSnapshot runs against hadoop 
 cluster where HBase is not installed on the same node as resourcemanager
 -

 Key: HBASE-9687
 URL: https://issues.apache.org/jira/browse/HBASE-9687
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Ted Yu
Assignee: Ted Yu
 Fix For: 0.98.0, 0.96.0

 Attachments: 9687-v1.patch


 First line below was the command, launched from gateway machine:
 {code}
 $ hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot 
 -Dfs.default.name=hdfs://hor17n25:8020/ 
 -Dhbase.rootdir=hdfs://hor17n25:8020/apps/hbase/data/ -snapshot 
 snapshot_tableone -copy-to hdfs://hor15n02:8020/apps/hbase/data/ -mappers 1
 13/09/30 17:23:56 WARN conf.Configuration: hbase-site.xml:an attempt to 
 override final parameter: dfs.support.append; Ignoring.
 13/09/30 17:23:57 INFO Configuration.deprecation: hadoop.native.lib is 
 deprecated. Instead, use io.native.lib.available
 13/09/30 17:23:57 INFO util.FSVisitor: No logs under 
 directory:hdfs://hor17n25:8020/apps/hbase/data/.hbase-snapshot/snapshot_tableone/WALs
 13/09/30 17:23:57 WARN conf.Configuration: hbase-site.xml:an attempt to 
 override final parameter: dfs.support.append; Ignoring.
 13/09/30 17:23:57 INFO client.RMProxy: Connecting to ResourceManager at 
 hor17n25/:8032
 13/09/30 17:23:57 INFO zlib.ZlibFactory: Successfully loaded  initialized 
 native-zlib library
 13/09/30 17:23:57 INFO compress.CodecPool: Got brand-new compressor .deflate
 13/09/30 17:23:57 WARN conf.Configuration: hbase-site.xml:an attempt to 
 override final parameter: dfs.support.append; Ignoring.
 13/09/30 17:23:57 INFO client.RMProxy: Connecting to ResourceManager at 
 hor17n25/:8032
 13/09/30 17:23:58 INFO input.FileInputFormat: Total input paths to process : 1
 13/09/30 17:23:58 INFO mapreduce.JobSubmitter: number of splits:1
 13/09/30 17:23:58 INFO Configuration.deprecation: user.name is deprecated. 
 Instead, use mapreduce.job.user.name
 13/09/30 17:23:58 INFO Configuration.deprecation: mapred.jar is deprecated. 
 Instead, use mapreduce.job.jar
 13/09/30 17:23:58 INFO Configuration.deprecation: fs.default.name is 
 deprecated. Instead, use fs.defaultFS
 13/09/30 17:23:58 INFO Configuration.deprecation: 
 mapred.map.tasks.speculative.execution is deprecated. Instead, use 
 mapreduce.map.speculative
 13/09/30 17:23:58 INFO Configuration.deprecation: mapred.reduce.tasks is 
 deprecated. Instead, use mapreduce.job.reduces
 13/09/30 17:23:58 INFO Configuration.deprecation: mapreduce.map.class is 
 deprecated. Instead, use mapreduce.job.map.class
 13/09/30 17:23:58 INFO Configuration.deprecation: mapred.job.name is 
 deprecated. Instead, use mapreduce.job.name
 13/09/30 17:23:58 INFO Configuration.deprecation: mapreduce.inputformat.class 
 is deprecated. Instead, use mapreduce.job.inputformat.class
 13/09/30 17:23:58 INFO Configuration.deprecation: mapred.input.dir is 
 deprecated. Instead, use mapreduce.input.fileinputformat.inputdir
 13/09/30 17:23:58 INFO Configuration.deprecation: 
 mapreduce.outputformat.class is deprecated. Instead, use 
 mapreduce.job.outputformat.class
 13/09/30 17:23:58 INFO Configuration.deprecation: mapred.map.tasks is 
 deprecated. Instead, use mapreduce.job.maps
 13/09/30 17:23:58 INFO Configuration.deprecation: mapred.working.dir is 
 deprecated. Instead, use mapreduce.job.working.dir
 13/09/30 17:23:58 INFO mapreduce.JobSubmitter: Submitting tokens for job: 
 job_1380335340676_0003
 13/09/30 17:23:58 INFO impl.YarnClientImpl: Submitted application 
 application_1380335340676_0003 to ResourceManager at hor17n25/:8032
 13/09/30 17:23:58 INFO mapreduce.Job: The url to track the job: 
 http://hor17n25:8088/proxy/application_1380335340676_0003/
 13/09/30 17:23:58 INFO mapreduce.Job: Running job: job_1380335340676_0003
 13/09/30 17:24:03 INFO mapreduce.Job: Job job_1380335340676_0003 running in 
 uber mode : false
 13/09/30 17:24:03 INFO mapreduce.Job: map 0% reduce 0%
 13/09/30 17:24:06 INFO mapreduce.Job: Task Id : 
 attempt_1380335340676_0003_m_00_0, Status : FAILED
 Error: java.lang.ClassNotFoundException: org.apache.hadoop.hbase.TableName
 at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
 at

[jira] [Updated] (HBASE-9687) ClassNotFoundException is thrown when ExportSnapshot runs against hadoop cluster where HBase is not installed on the same node as resourcemanager


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

Ted Yu updated HBASE-9687:
--

Attachment: (was: 9687-v8.txt)

 ClassNotFoundException is thrown when ExportSnapshot runs against hadoop 
 cluster where HBase is not installed on the same node as resourcemanager
 -

 Key: HBASE-9687
 URL: https://issues.apache.org/jira/browse/HBASE-9687
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Ted Yu
Assignee: Ted Yu
 Fix For: 0.98.0, 0.96.0

 Attachments: 9687-v1.patch


 First line below was the command, launched from gateway machine:
 {code}
 $ hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot 
 -Dfs.default.name=hdfs://hor17n25:8020/ 
 -Dhbase.rootdir=hdfs://hor17n25:8020/apps/hbase/data/ -snapshot 
 snapshot_tableone -copy-to hdfs://hor15n02:8020/apps/hbase/data/ -mappers 1
 13/09/30 17:23:56 WARN conf.Configuration: hbase-site.xml:an attempt to 
 override final parameter: dfs.support.append; Ignoring.
 13/09/30 17:23:57 INFO Configuration.deprecation: hadoop.native.lib is 
 deprecated. Instead, use io.native.lib.available
 13/09/30 17:23:57 INFO util.FSVisitor: No logs under 
 directory:hdfs://hor17n25:8020/apps/hbase/data/.hbase-snapshot/snapshot_tableone/WALs
 13/09/30 17:23:57 WARN conf.Configuration: hbase-site.xml:an attempt to 
 override final parameter: dfs.support.append; Ignoring.
 13/09/30 17:23:57 INFO client.RMProxy: Connecting to ResourceManager at 
 hor17n25/:8032
 13/09/30 17:23:57 INFO zlib.ZlibFactory: Successfully loaded  initialized 
 native-zlib library
 13/09/30 17:23:57 INFO compress.CodecPool: Got brand-new compressor .deflate
 13/09/30 17:23:57 WARN conf.Configuration: hbase-site.xml:an attempt to 
 override final parameter: dfs.support.append; Ignoring.
 13/09/30 17:23:57 INFO client.RMProxy: Connecting to ResourceManager at 
 hor17n25/:8032
 13/09/30 17:23:58 INFO input.FileInputFormat: Total input paths to process : 1
 13/09/30 17:23:58 INFO mapreduce.JobSubmitter: number of splits:1
 13/09/30 17:23:58 INFO Configuration.deprecation: user.name is deprecated. 
 Instead, use mapreduce.job.user.name
 13/09/30 17:23:58 INFO Configuration.deprecation: mapred.jar is deprecated. 
 Instead, use mapreduce.job.jar
 13/09/30 17:23:58 INFO Configuration.deprecation: fs.default.name is 
 deprecated. Instead, use fs.defaultFS
 13/09/30 17:23:58 INFO Configuration.deprecation: 
 mapred.map.tasks.speculative.execution is deprecated. Instead, use 
 mapreduce.map.speculative
 13/09/30 17:23:58 INFO Configuration.deprecation: mapred.reduce.tasks is 
 deprecated. Instead, use mapreduce.job.reduces
 13/09/30 17:23:58 INFO Configuration.deprecation: mapreduce.map.class is 
 deprecated. Instead, use mapreduce.job.map.class
 13/09/30 17:23:58 INFO Configuration.deprecation: mapred.job.name is 
 deprecated. Instead, use mapreduce.job.name
 13/09/30 17:23:58 INFO Configuration.deprecation: mapreduce.inputformat.class 
 is deprecated. Instead, use mapreduce.job.inputformat.class
 13/09/30 17:23:58 INFO Configuration.deprecation: mapred.input.dir is 
 deprecated. Instead, use mapreduce.input.fileinputformat.inputdir
 13/09/30 17:23:58 INFO Configuration.deprecation: 
 mapreduce.outputformat.class is deprecated. Instead, use 
 mapreduce.job.outputformat.class
 13/09/30 17:23:58 INFO Configuration.deprecation: mapred.map.tasks is 
 deprecated. Instead, use mapreduce.job.maps
 13/09/30 17:23:58 INFO Configuration.deprecation: mapred.working.dir is 
 deprecated. Instead, use mapreduce.job.working.dir
 13/09/30 17:23:58 INFO mapreduce.JobSubmitter: Submitting tokens for job: 
 job_1380335340676_0003
 13/09/30 17:23:58 INFO impl.YarnClientImpl: Submitted application 
 application_1380335340676_0003 to ResourceManager at hor17n25/:8032
 13/09/30 17:23:58 INFO mapreduce.Job: The url to track the job: 
 http://hor17n25:8088/proxy/application_1380335340676_0003/
 13/09/30 17:23:58 INFO mapreduce.Job: Running job: job_1380335340676_0003
 13/09/30 17:24:03 INFO mapreduce.Job: Job job_1380335340676_0003 running in 
 uber mode : false
 13/09/30 17:24:03 INFO mapreduce.Job: map 0% reduce 0%
 13/09/30 17:24:06 INFO mapreduce.Job: Task Id : 
 attempt_1380335340676_0003_m_00_0, Status : FAILED
 Error: java.lang.ClassNotFoundException: org.apache.hadoop.hbase.TableName
 at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
 at

[jira] [Updated] (HBASE-9612) Ability to batch edits destined to different regions


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

stack updated HBASE-9612:
-

Attachment: 9612v12.txt

Fix javadoc.  The failed test looks unrelated and passes fine locally but it 
has failed twice so suspicious... looking.

 Ability to batch edits destined to different regions
 

 Key: HBASE-9612
 URL: https://issues.apache.org/jira/browse/HBASE-9612
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.0, 0.95.1, 0.95.2, 0.96.0
Reporter: Benoit Sigoure
Assignee: stack
Priority: Critical
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-fix-packaging-by-region-in-MultiServerCallable.patch, 9612.096.v5.txt, 
 9612revert.txt, 9612v10.txt, 9612v11.txt, 9612v12.txt, 9612v2.txt, 
 9612v3.txt, 9612v4.txt, 9612v5.txt, 9612v5.txt, 9612v5.txt, 9612v7.txt, 
 9612v8.096.txt, 9612v8.txt, 9612v9.txt, 9612v9.txt, 9612.wip.txt


 The old (pre-PB) multi and multiPut RPCs allowed one to batch edits 
 destined to different regions.  Seems like we've lost this ability after the 
 switch to protobufs.
 The {{MultiRequest}} only contains one {{RegionSpecifier}}, and a list of 
 {{MultiAction}}.  The {{MultiAction}} message is contains either a single 
 {{MutationProto}} or a {{Get}} (but not both – so its name is misleading as 
 there is nothing multi about it).  Also it seems redundant with 
 {{MultiGetRequest}}, I'm not sure what's the point of supporting {{Get}} in 
 {{MultiAction}}.
 I propose that we change {{MultiRequest}} to be a just a list of 
 {{MultiAction}}, and {{MultiAction}} will contain the {{RegionSpecifier}}, 
 the {{bool atomic}} and a list of {{MutationProto}}.  This would be a 
 non-backward compatible protobuf change.
 If we want we can support mixing edits and reads, in which case we'd also add 
 a list of {{Get}} in {{MultiAction}}, and we'd have support having both that 
 list and the list of {{MutationProto}} set at the same time.  But this is a 
 bonus and can be done later (in a backward compatible manner, hence no need 
 to rush on this one).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9612) Ability to batch edits destined to different regions


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

stack commented on HBASE-9612:
--

I spent time looking into trying to make [~eclark] less uncomfortable and doing 
what [~tsuna] suggested a while back (perhaps off-issue), sorting out the 
passed in actions into gets and mutations and then running a multiget for the 
gets and a multi call for the mutations. Digging it seemed doable if I made 
multiget look like multi; AsyncProcess has an executor pool so I was thinking I 
could add one executor for the gets and another for the mutations per 
regionserver.  As long as I was careful w/ the results/exceptions keeping their 
indexes running and aligned, I should be able to match up the returns before 
giving it all back to the client.

But then I found the multiget has same issue as multirequest in that it only 
allows a regions' worth of gets to run at a time against a server.  Trying to 
fix multiget, I was just reproducing the new multi model (a 'fixed' multiget 
would have one or more per-region pbs to hold a set of Gets).

So, I am going to just remove multiGet.  We only use it in one place inside in 
the exists(ListGet) call.   If you want to do a multiget, you'll do this new 
'universal' multi call.

Later, we can come along and add new methods to do multiGet and multiMutation 
if worth the effort.

 Ability to batch edits destined to different regions
 

 Key: HBASE-9612
 URL: https://issues.apache.org/jira/browse/HBASE-9612
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.0, 0.95.1, 0.95.2, 0.96.0
Reporter: Benoit Sigoure
Assignee: stack
Priority: Critical
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-fix-packaging-by-region-in-MultiServerCallable.patch, 9612.096.v5.txt, 
 9612revert.txt, 9612v10.txt, 9612v11.txt, 9612v12.txt, 9612v2.txt, 
 9612v3.txt, 9612v4.txt, 9612v5.txt, 9612v5.txt, 9612v5.txt, 9612v7.txt, 
 9612v8.096.txt, 9612v8.txt, 9612v9.txt, 9612v9.txt, 9612.wip.txt


 The old (pre-PB) multi and multiPut RPCs allowed one to batch edits 
 destined to different regions.  Seems like we've lost this ability after the 
 switch to protobufs.
 The {{MultiRequest}} only contains one {{RegionSpecifier}}, and a list of 
 {{MultiAction}}.  The {{MultiAction}} message is contains either a single 
 {{MutationProto}} or a {{Get}} (but not both – so its name is misleading as 
 there is nothing multi about it).  Also it seems redundant with 
 {{MultiGetRequest}}, I'm not sure what's the point of supporting {{Get}} in 
 {{MultiAction}}.
 I propose that we change {{MultiRequest}} to be a just a list of 
 {{MultiAction}}, and {{MultiAction}} will contain the {{RegionSpecifier}}, 
 the {{bool atomic}} and a list of {{MutationProto}}.  This would be a 
 non-backward compatible protobuf change.
 If we want we can support mixing edits and reads, in which case we'd also add 
 a list of {{Get}} in {{MultiAction}}, and we'd have support having both that 
 list and the list of {{MutationProto}} set at the same time.  But this is a 
 bonus and can be done later (in a backward compatible manner, hence no need 
 to rush on this one).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9686) More temporary test files are being left in /tmp/hbase-user


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

Hudson commented on HBASE-9686:
---

SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #776 (See 
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/776/])
HBASE-9686 More temporary test files are being left in /tmp/hbase-user 
(jmhsieh: rev 1528984)
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestCase.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestScannerSelectionUsingKeyRange.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestScannerSelectionUsingTTL.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/master/handler/TestTableDescriptorModification.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestAtomicOperation.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCacheOnWriteInSchema.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompaction.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionBusyWait.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestParallelPut.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessControlFilter.java


 More temporary test files are being left in /tmp/hbase-user
 -

 Key: HBASE-9686
 URL: https://issues.apache.org/jira/browse/HBASE-9686
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.96.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9686.patch, hbase-9686.v2.patch


 There is currently about 160MB of stuff being left behind in after a unit 
 test run in our jenkins setup.
 Table names left behind indicate that it is due to these classes.
 TestCompaction
 Either TestForceCacheImporatntBlocks or TestScannerSelectionUingTTL or 
 TestScannerSelectionUsingKeyRange
 TestHRegion



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9693) Fix javadoc warnings


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

Hudson commented on HBASE-9693:
---

SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #776 (See 
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/776/])
HBASE-9693 Fix javadoc warnings (jxiang: rev 1528938)
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/catalog/MetaReader.java
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/coprocessor/AggregationClient.java
* /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/Tag.java
* 
/hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/io/compress/Compression.java
* 
/hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/executor/EventHandler.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/Reference.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFile.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/bucket/BucketCache.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/migration/UpgradeTo96.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/procedure/ProcedureCoordinator.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogSplitter.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/TableAuthManager.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HFileV1Detector.java
* 
/hbase/trunk/hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftServerRunner.java


 Fix javadoc warnings
 

 Key: HBASE-9693
 URL: https://issues.apache.org/jira/browse/HBASE-9693
 Project: HBase
  Issue Type: Task
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Fix For: 0.98.0, 0.96.0

 Attachments: trunk-9693.patch


 There are not many javadoc warnings.  We can fix them all.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9698) HBCK does not handle tables with no regions left


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

Hudson commented on HBASE-9698:
---

SUCCESS: Integrated in HBase-TRUNK #4589 (See 
[https://builds.apache.org/job/HBase-TRUNK/4589/])
HBASE-9698 HBCK does not handle tables with no regions left (enis: rev 1528989)
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsck.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/util/hbck/TestOfflineMetaRebuildHole.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/util/hbck/TestOfflineMetaRebuildOverlap.java


 HBCK does not handle tables with no regions left
 

 Key: HBASE-9698
 URL: https://issues.apache.org/jira/browse/HBASE-9698
 Project: HBase
  Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9698_v1.patch, hbase-9698_v2.patch


 hbck does not handle the case where all the regions of a table is gone. To 
 reproduce this: 
 1. create table with one region 
 2. delete the region directory
 3. run hbck --repair, which removes the region from meta as well 
 4. now, the meta won't contain the region, but the table dir in hdfs will be 
 there. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9698) HBCK does not handle tables with no regions left


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

Hudson commented on HBASE-9698:
---

SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #776 (See 
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/776/])
HBASE-9698 HBCK does not handle tables with no regions left (enis: rev 1528989)
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsck.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/util/hbck/TestOfflineMetaRebuildHole.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/util/hbck/TestOfflineMetaRebuildOverlap.java


 HBCK does not handle tables with no regions left
 

 Key: HBASE-9698
 URL: https://issues.apache.org/jira/browse/HBASE-9698
 Project: HBase
  Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9698_v1.patch, hbase-9698_v2.patch


 hbck does not handle the case where all the regions of a table is gone. To 
 reproduce this: 
 1. create table with one region 
 2. delete the region directory
 3. run hbck --repair, which removes the region from meta as well 
 4. now, the meta won't contain the region, but the table dir in hdfs will be 
 there. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9686) More temporary test files are being left in /tmp/hbase-user


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

Hudson commented on HBASE-9686:
---

SUCCESS: Integrated in HBase-TRUNK #4589 (See 
[https://builds.apache.org/job/HBase-TRUNK/4589/])
HBASE-9686 More temporary test files are being left in /tmp/hbase-user 
(jmhsieh: rev 1528984)
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestCase.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestScannerSelectionUsingKeyRange.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestScannerSelectionUsingTTL.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/master/handler/TestTableDescriptorModification.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestAtomicOperation.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCacheOnWriteInSchema.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompaction.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionBusyWait.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestParallelPut.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessControlFilter.java


 More temporary test files are being left in /tmp/hbase-user
 -

 Key: HBASE-9686
 URL: https://issues.apache.org/jira/browse/HBASE-9686
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.96.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9686.patch, hbase-9686.v2.patch


 There is currently about 160MB of stuff being left behind in after a unit 
 test run in our jenkins setup.
 Table names left behind indicate that it is due to these classes.
 TestCompaction
 Either TestForceCacheImporatntBlocks or TestScannerSelectionUingTTL or 
 TestScannerSelectionUsingKeyRange
 TestHRegion



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9612) Ability to batch edits destined to different regions


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

Hadoop QA commented on HBASE-9612:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12606644/9612v12.txt
  against trunk revision .

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

{color:green}+1 tests included{color}.  The patch appears to include 18 new 
or modified tests.

{color:green}+1 hadoop1.0{color}.  The patch compiles against the hadoop 
1.0 profile.

{color:green}+1 hadoop2.0{color}.  The patch compiles against the hadoop 
2.0 profile.

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

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

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) 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:red}-1 site{color}.  The patch appears to cause mvn site goal to 
fail.

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
   
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7459//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7459//console

This message is automatically generated.

 Ability to batch edits destined to different regions
 

 Key: HBASE-9612
 URL: https://issues.apache.org/jira/browse/HBASE-9612
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.0, 0.95.1, 0.95.2, 0.96.0
Reporter: Benoit Sigoure
Assignee: stack
Priority: Critical
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-fix-packaging-by-region-in-MultiServerCallable.patch, 9612.096.v5.txt, 
 9612revert.txt, 9612v10.txt, 9612v11.txt, 9612v12.txt, 9612v2.txt, 
 9612v3.txt, 9612v4.txt, 9612v5.txt, 9612v5.txt, 9612v5.txt, 9612v7.txt, 
 9612v8.096.txt, 9612v8.txt, 9612v9.txt, 9612v9.txt, 9612.wip.txt


 The old (pre-PB) multi and multiPut RPCs allowed one to batch edits 
 destined to different regions.  Seems like we've lost this ability after the 
 switch to protobufs.
 The {{MultiRequest}} only contains one {{RegionSpecifier}}, and a list of 
 {{MultiAction}}.  The {{MultiAction}} message is contains either a single 
 {{MutationProto}} or a {{Get}} (but not both – so its name is misleading as 
 there is nothing multi about it).  Also it seems redundant with 
 {{MultiGetRequest}}, I'm not sure what's the point of supporting {{Get}} in 
 {{MultiAction}}.
 I propose that we change {{MultiRequest}} to be a just a list of 
 {{MultiAction}}, and {{MultiAction}} will contain the {{RegionSpecifier}}, 
 the {{bool atomic}} and a list of {{MutationProto}}.  This would be a 
 non-backward compatible protobuf change.
 If we want we can support mixing edits and reads, in which case we'd also add 
 a list of {{Get}} in {{MultiAction}}, and we'd have support having both that 
 list and the list of {{MutationProto}} set at the same time.  But this is a 
 bonus and can be

[jira] [Commented] (HBASE-9686) More temporary test files are being left in /tmp/hbase-user


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

Hudson commented on HBASE-9686:
---

SUCCESS: Integrated in hbase-0.96 #121 (See 
[https://builds.apache.org/job/hbase-0.96/121/])
HBASE-9686 More temporary test files are being left in /tmp/hbase-user 
(jmhsieh: rev 1528985)
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestCase.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestScannerSelectionUsingTTL.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/master/handler/TestTableDescriptorModification.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestAtomicOperation.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCacheOnWriteInSchema.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompaction.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionBusyWait.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestParallelPut.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessControlFilter.java


 More temporary test files are being left in /tmp/hbase-user
 -

 Key: HBASE-9686
 URL: https://issues.apache.org/jira/browse/HBASE-9686
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.96.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9686.patch, hbase-9686.v2.patch


 There is currently about 160MB of stuff being left behind in after a unit 
 test run in our jenkins setup.
 Table names left behind indicate that it is due to these classes.
 TestCompaction
 Either TestForceCacheImporatntBlocks or TestScannerSelectionUingTTL or 
 TestScannerSelectionUsingKeyRange
 TestHRegion



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9698) HBCK does not handle tables with no regions left


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

Hudson commented on HBASE-9698:
---

SUCCESS: Integrated in hbase-0.96 #121 (See 
[https://builds.apache.org/job/hbase-0.96/121/])
HBASE-9698 HBCK does not handle tables with no regions left (enis: rev 1528991)
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsck.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/util/hbck/TestOfflineMetaRebuildHole.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/util/hbck/TestOfflineMetaRebuildOverlap.java


 HBCK does not handle tables with no regions left
 

 Key: HBASE-9698
 URL: https://issues.apache.org/jira/browse/HBASE-9698
 Project: HBase
  Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9698_v1.patch, hbase-9698_v2.patch


 hbck does not handle the case where all the regions of a table is gone. To 
 reproduce this: 
 1. create table with one region 
 2. delete the region directory
 3. run hbck --repair, which removes the region from meta as well 
 4. now, the meta won't contain the region, but the table dir in hdfs will be 
 there. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9703) DistributedHBaseCluster should not throw exceptions, but do a best effort restore


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

Enis Soztutar updated HBASE-9703:
-

Status: Patch Available  (was: Open)

 DistributedHBaseCluster should not throw exceptions, but do a best effort 
 restore
 -

 Key: HBASE-9703
 URL: https://issues.apache.org/jira/browse/HBASE-9703
 Project: HBase
  Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.98.0, 0.96.1

 Attachments: hbase-9703_v1.patch


 At the end of integration tests, we are calling 
 DistributedCluster.restoreCluster() in case CM has killed nodes so that we 
 can leave the cluster in the same state that we have taken over. 
 However, if CM is not used in a test (for example ITLoadAndVerify), but some 
 regions servers die, or an external daemon kills the servers, we will still  
 try to restore at the end of the test which may or may not succeed (depending 
 on configuration, the region server going being unaccessible, etc. )
 We can do two things, either do a best effort restore cluster which will not 
 fail the test if there are any errors, or we can skip running restore if no 
 disruptive actions have taken place. 
 I am leaning towards the former one, since if an RS goes down with or w/o CM 
 due to bad disk etc., we cannot restore the cluster, but we should not fail 
 the test in this case. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9703) DistributedHBaseCluster should not throw exceptions, but do a best effort restore

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

Hadoop QA commented on HBASE-9703:
--

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12606513/hbase-9703_v1.patch
against trunk revision .

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

{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.

{color:red}-1 patch{color}. The patch command could not apply the patch.

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

This message is automatically generated.

DistributedHBaseCluster should not throw exceptions, but do a best effort
restore
-

Key: HBASE-9703
URL: https://issues.apache.org/jira/browse/HBASE-9703
Project: HBase
Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Fix For: 0.98.0, 0.96.1

Attachments: hbase-9703_v1.patch

At the end of integration tests, we are calling
DistributedCluster.restoreCluster() in case CM has killed nodes so that we
can leave the cluster in the same state that we have taken over.
However, if CM is not used in a test (for example ITLoadAndVerify), but some
regions servers die, or an external daemon kills the servers, we will still
try to restore at the end of the test which may or may not succeed (depending
on configuration, the region server going being unaccessible, etc. )
We can do two things, either do a best effort restore cluster which will not
fail the test if there are any errors, or we can skip running restore if no
disruptive actions have taken place.
I am leaning towards the former one, since if an RS goes down with or w/o CM
due to bad disk etc., we cannot restore the cluster, but we should not fail
the test in this case.

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9703) DistributedHBaseCluster should not throw exceptions, but do a best effort restore

2013-10-03 Thread Sergey Shelukhin (JIRA)


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

Sergey Shelukhin commented on HBASE-9703:
-

Does = short circuit? Might not call other methods after one failure.
Spacing is wrong in places.
Otherwise looks reasonable.
Can you post RB?

 DistributedHBaseCluster should not throw exceptions, but do a best effort 
 restore
 -

 Key: HBASE-9703
 URL: https://issues.apache.org/jira/browse/HBASE-9703
 Project: HBase
  Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.98.0, 0.96.1

 Attachments: hbase-9703_v1.patch


 At the end of integration tests, we are calling 
 DistributedCluster.restoreCluster() in case CM has killed nodes so that we 
 can leave the cluster in the same state that we have taken over. 
 However, if CM is not used in a test (for example ITLoadAndVerify), but some 
 regions servers die, or an external daemon kills the servers, we will still  
 try to restore at the end of the test which may or may not succeed (depending 
 on configuration, the region server going being unaccessible, etc. )
 We can do two things, either do a best effort restore cluster which will not 
 fail the test if there are any errors, or we can skip running restore if no 
 disruptive actions have taken place. 
 I am leaning towards the former one, since if an RS goes down with or w/o CM 
 due to bad disk etc., we cannot restore the cluster, but we should not fail 
 the test in this case. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9703) DistributedHBaseCluster should not throw exceptions, but do a best effort restore


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

Enis Soztutar commented on HBASE-9703:
--

RB up with a second version:
https://reviews.apache.org/r/14473/
Fixed using =, which caused methods not being executed if success == false. 

 DistributedHBaseCluster should not throw exceptions, but do a best effort 
 restore
 -

 Key: HBASE-9703
 URL: https://issues.apache.org/jira/browse/HBASE-9703
 Project: HBase
  Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.98.0, 0.96.1

 Attachments: hbase-9703_v1.patch


 At the end of integration tests, we are calling 
 DistributedCluster.restoreCluster() in case CM has killed nodes so that we 
 can leave the cluster in the same state that we have taken over. 
 However, if CM is not used in a test (for example ITLoadAndVerify), but some 
 regions servers die, or an external daemon kills the servers, we will still  
 try to restore at the end of the test which may or may not succeed (depending 
 on configuration, the region server going being unaccessible, etc. )
 We can do two things, either do a best effort restore cluster which will not 
 fail the test if there are any errors, or we can skip running restore if no 
 disruptive actions have taken place. 
 I am leaning towards the former one, since if an RS goes down with or w/o CM 
 due to bad disk etc., we cannot restore the cluster, but we should not fail 
 the test in this case. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9703) DistributedHBaseCluster should not throw exceptions, but do a best effort restore


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

Enis Soztutar updated HBASE-9703:
-

Attachment: hbase-9703_v3.patch

rebased. 

 DistributedHBaseCluster should not throw exceptions, but do a best effort 
 restore
 -

 Key: HBASE-9703
 URL: https://issues.apache.org/jira/browse/HBASE-9703
 Project: HBase
  Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.98.0, 0.96.1

 Attachments: hbase-9703_v1.patch, hbase-9703_v3.patch


 At the end of integration tests, we are calling 
 DistributedCluster.restoreCluster() in case CM has killed nodes so that we 
 can leave the cluster in the same state that we have taken over. 
 However, if CM is not used in a test (for example ITLoadAndVerify), but some 
 regions servers die, or an external daemon kills the servers, we will still  
 try to restore at the end of the test which may or may not succeed (depending 
 on configuration, the region server going being unaccessible, etc. )
 We can do two things, either do a best effort restore cluster which will not 
 fail the test if there are any errors, or we can skip running restore if no 
 disruptive actions have taken place. 
 I am leaning towards the former one, since if an RS goes down with or w/o CM 
 due to bad disk etc., we cannot restore the cluster, but we should not fail 
 the test in this case. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-4811) Support reverse Scan


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

Lars Hofhansl commented on HBASE-4811:
--

Looking through the patch I don't see why forward scanning would be slower. 
There's a bit more function dispatching and a bit more inheritance, but the 
JVM should automatically do the right thing (inline methods, etc). So I am a 
bit baffled.
Did another test with slightly changed code, still brings the runtime from 17.2 
to 18.2 secs (test varies slightly from initial test).


 Support reverse Scan
 

 Key: HBASE-4811
 URL: https://issues.apache.org/jira/browse/HBASE-4811
 Project: HBase
  Issue Type: New Feature
  Components: Client
Affects Versions: 0.20.6, 0.94.7
Reporter: John Carrino
Assignee: chunhui shen
 Fix For: 0.98.0

 Attachments: 4811-0.94-v3.txt, 4811-trunk-v10.txt, 
 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt, hbase-4811-0.94 
 v21.patch, HBase-4811-0.94-v2.txt, hbase-4811-trunkv11.patch, 
 hbase-4811-trunkv12.patch, hbase-4811-trunkv13.patch, 
 hbase-4811-trunkv14.patch, hbase-4811-trunkv15.patch, 
 hbase-4811-trunkv16.patch, hbase-4811-trunkv17.patch, 
 hbase-4811-trunkv18.patch, hbase-4811-trunkv19.patch, 
 hbase-4811-trunkv1.patch, hbase-4811-trunkv20.patch, 
 hbase-4811-trunkv21.patch, hbase-4811-trunkv4.patch, 
 hbase-4811-trunkv6.patch, hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, 
 hbase-4811-trunkv9.patch


 Reversed scan means scan the rows backward. 
 And StartRow bigger than StopRow in a reversed scan.
 For example, for the following rows:
 aaa/c1:q1/value1
 aaa/c1:q2/value2
 bbb/c1:q1/value1
 bbb/c1:q2/value2
 ccc/c1:q1/value1
 ccc/c1:q2/value2
 ddd/c1:q1/value1
 ddd/c1:q2/value2
 eee/c1:q1/value1
 eee/c1:q2/value2
 you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
 Scan scan = new Scan();
 scan.setStartRow('ddd');
 scan.setStopRow('bbb');
 scan.setReversed(true);
 for(Result result:htable.getScanner(scan)){
  System.out.println(result);
 }
 Aslo you could do the reversed scan with shell like this:
 hbase scan 'table',{REVERSED = true,STARTROW='ddd', STOPROW='bbb'}
 And the output is:
 ddd/c1:q1/value1
 ddd/c1:q2/value2
 ccc/c1:q1/value1
 ccc/c1:q2/value2
 NOTE: when setting reversed as true for a client scan, you must set the start 
 row, else will throw exception. Through {@link 
 Scan#createBiggestByteArray(int)},you could get a big enough byte array as 
 the start row
 All the documentation I find about HBase says that if you want forward and 
 reverse scans you should just build 2 tables and one be ascending and one 
 descending.  Is there a fundamental reason that HBase only supports forward 
 Scan?  It seems like a lot of extra space overhead and coding overhead (to 
 keep them in sync) to support 2 tables.  
 I am assuming this has been discussed before, but I can't find the 
 discussions anywhere about it or why it would be infeasible.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-7404) Bucket Cache:A solution about CMS,Heap Fragment and Big Cache on HBASE

2013-10-03 Thread Jerry He (JIRA)


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

Jerry He commented on HBASE-7404:
-

We'd like to have this in 0.94 too.
On the other hand, just to confirm, if this feature is not configured/enabled, 
there is no impact to anything existing, correct?

 Bucket Cache:A solution about CMS,Heap Fragment and Big Cache on HBASE
 --

 Key: HBASE-7404
 URL: https://issues.apache.org/jira/browse/HBASE-7404
 Project: HBase
  Issue Type: New Feature
Affects Versions: 0.94.3
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.95.0

 Attachments: 7404-0.94-fixed-lines.txt, 7404-trunk-v10.patch, 
 7404-trunk-v11.patch, 7404-trunk-v12.patch, 7404-trunk-v13.patch, 
 7404-trunk-v13.txt, 7404-trunk-v14.patch, BucketCache.pdf, 
 hbase-7404-94v2.patch, HBASE-7404-backport-0.94.patch, 
 hbase-7404-trunkv2.patch, hbase-7404-trunkv9.patch, Introduction of Bucket 
 Cache.pdf


 First, thanks @neil from Fusion-IO share the source code.
 Usage:
 1.Use bucket cache as main memory cache, configured as the following:
 –hbase.bucketcache.ioengine heap
 –hbase.bucketcache.size 0.4 (size for bucket cache, 0.4 is a percentage of 
 max heap size)
 2.Use bucket cache as a secondary cache, configured as the following:
 –hbase.bucketcache.ioengine file:/disk1/hbase/cache.data(The file path 
 where to store the block data)
 –hbase.bucketcache.size 1024 (size for bucket cache, unit is MB, so 1024 
 means 1GB)
 –hbase.bucketcache.combinedcache.enabled false (default value being true)
 See more configurations from org.apache.hadoop.hbase.io.hfile.CacheConfig and 
 org.apache.hadoop.hbase.io.hfile.bucket.BucketCache
 What's Bucket Cache? 
 It could greatly decrease CMS and heap fragment by GC
 It support a large cache space for High Read Performance by using high speed 
 disk like Fusion-io
 1.An implementation of block cache like LruBlockCache
 2.Self manage blocks' storage position through Bucket Allocator
 3.The cached blocks could be stored in the memory or file system
 4.Bucket Cache could be used as a mainly block cache(see CombinedBlockCache), 
 combined with LruBlockCache to decrease CMS and fragment by GC.
 5.BucketCache also could be used as a secondary cache(e.g. using Fusionio to 
 store block) to enlarge cache space
 How about SlabCache?
 We have studied and test SlabCache first, but the result is bad, because:
 1.SlabCache use SingleSizeCache, its use ratio of memory is low because kinds 
 of block size, especially using DataBlockEncoding
 2.SlabCache is uesd in DoubleBlockCache, block is cached both in SlabCache 
 and LruBlockCache, put the block to LruBlockCache again if hit in SlabCache , 
 it causes CMS and heap fragment don't get any better
 3.Direct heap performance is not good as heap, and maybe cause OOM, so we 
 recommend using heap engine 
 See more in the attachment and in the patch



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-7404) Bucket Cache:A solution about CMS,Heap Fragment and Big Cache on HBASE


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

Lars Hofhansl commented on HBASE-7404:
--

That is correct.

 Bucket Cache:A solution about CMS,Heap Fragment and Big Cache on HBASE
 --

 Key: HBASE-7404
 URL: https://issues.apache.org/jira/browse/HBASE-7404
 Project: HBase
  Issue Type: New Feature
Affects Versions: 0.94.3
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.95.0

 Attachments: 7404-0.94-fixed-lines.txt, 7404-trunk-v10.patch, 
 7404-trunk-v11.patch, 7404-trunk-v12.patch, 7404-trunk-v13.patch, 
 7404-trunk-v13.txt, 7404-trunk-v14.patch, BucketCache.pdf, 
 hbase-7404-94v2.patch, HBASE-7404-backport-0.94.patch, 
 hbase-7404-trunkv2.patch, hbase-7404-trunkv9.patch, Introduction of Bucket 
 Cache.pdf


 First, thanks @neil from Fusion-IO share the source code.
 Usage:
 1.Use bucket cache as main memory cache, configured as the following:
 –hbase.bucketcache.ioengine heap
 –hbase.bucketcache.size 0.4 (size for bucket cache, 0.4 is a percentage of 
 max heap size)
 2.Use bucket cache as a secondary cache, configured as the following:
 –hbase.bucketcache.ioengine file:/disk1/hbase/cache.data(The file path 
 where to store the block data)
 –hbase.bucketcache.size 1024 (size for bucket cache, unit is MB, so 1024 
 means 1GB)
 –hbase.bucketcache.combinedcache.enabled false (default value being true)
 See more configurations from org.apache.hadoop.hbase.io.hfile.CacheConfig and 
 org.apache.hadoop.hbase.io.hfile.bucket.BucketCache
 What's Bucket Cache? 
 It could greatly decrease CMS and heap fragment by GC
 It support a large cache space for High Read Performance by using high speed 
 disk like Fusion-io
 1.An implementation of block cache like LruBlockCache
 2.Self manage blocks' storage position through Bucket Allocator
 3.The cached blocks could be stored in the memory or file system
 4.Bucket Cache could be used as a mainly block cache(see CombinedBlockCache), 
 combined with LruBlockCache to decrease CMS and fragment by GC.
 5.BucketCache also could be used as a secondary cache(e.g. using Fusionio to 
 store block) to enlarge cache space
 How about SlabCache?
 We have studied and test SlabCache first, but the result is bad, because:
 1.SlabCache use SingleSizeCache, its use ratio of memory is low because kinds 
 of block size, especially using DataBlockEncoding
 2.SlabCache is uesd in DoubleBlockCache, block is cached both in SlabCache 
 and LruBlockCache, put the block to LruBlockCache again if hit in SlabCache , 
 it causes CMS and heap fragment don't get any better
 3.Direct heap performance is not good as heap, and maybe cause OOM, so we 
 recommend using heap engine 
 See more in the attachment and in the patch



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9709) LogReplay throws NPE when no KVs to be replayed in a WALEdit


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

Jeffrey Zhong updated HBASE-9709:
-

Fix Version/s: (was: 0.96.1)

 LogReplay throws NPE when no KVs to be replayed in a WALEdit
 

 Key: HBASE-9709
 URL: https://issues.apache.org/jira/browse/HBASE-9709
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0
Reporter: Jeffrey Zhong
Assignee: Jeffrey Zhong
Priority: Minor

 This is regression from my recent checkin from hbase-9390 below is the 
 exception stack:
 {code}
 2013-10-03 09:34:32,735 ERROR [WriterThread-1] wal.HLogSplitter: Exiting 
 thread
 java.lang.NullPointerException
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$LogReplayOutputSink.groupEditsByServer(HLogSplitter.java:1489)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$LogReplayOutputSink.append(HLogSplitter.java:1368)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.writeBuffer(HLogSplitter.java:847)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.doRun(HLogSplitter.java:839)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.run(HLogSplitter.java:809)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (HBASE-9709) LogReplay throws NPE when no KVs to be replayed in a WALEdit

Jeffrey Zhong created HBASE-9709:


 Summary: LogReplay throws NPE when no KVs to be replayed in a 
WALEdit
 Key: HBASE-9709
 URL: https://issues.apache.org/jira/browse/HBASE-9709
 Project: HBase
  Issue Type: Bug
Reporter: Jeffrey Zhong
Priority: Minor


This is regression from my recent checkin from hbase-9390 below is the 
exception stack:

{code}
2013-10-03 09:34:32,735 ERROR [WriterThread-1] wal.HLogSplitter: Exiting thread
java.lang.NullPointerException
at 
org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$LogReplayOutputSink.groupEditsByServer(HLogSplitter.java:1489)
at 
org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$LogReplayOutputSink.append(HLogSplitter.java:1368)
at 
org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.writeBuffer(HLogSplitter.java:847)
at 
org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.doRun(HLogSplitter.java:839)
at 
org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.run(HLogSplitter.java:809)
{code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9709) LogReplay throws NPE when no KVs to be replayed in a WALEdit


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

Jeffrey Zhong updated HBASE-9709:
-

Affects Version/s: 0.96.0
Fix Version/s: 0.96.1
 Assignee: Jeffrey Zhong

 LogReplay throws NPE when no KVs to be replayed in a WALEdit
 

 Key: HBASE-9709
 URL: https://issues.apache.org/jira/browse/HBASE-9709
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0
Reporter: Jeffrey Zhong
Assignee: Jeffrey Zhong
Priority: Minor

 This is regression from my recent checkin from hbase-9390 below is the 
 exception stack:
 {code}
 2013-10-03 09:34:32,735 ERROR [WriterThread-1] wal.HLogSplitter: Exiting 
 thread
 java.lang.NullPointerException
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$LogReplayOutputSink.groupEditsByServer(HLogSplitter.java:1489)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$LogReplayOutputSink.append(HLogSplitter.java:1368)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.writeBuffer(HLogSplitter.java:847)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.doRun(HLogSplitter.java:839)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.run(HLogSplitter.java:809)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9703) DistributedHBaseCluster should not throw exceptions, but do a best effort restore

2013-10-03 Thread Sergey Shelukhin (JIRA)


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

Sergey Shelukhin commented on HBASE-9703:
-

lgtm

 DistributedHBaseCluster should not throw exceptions, but do a best effort 
 restore
 -

 Key: HBASE-9703
 URL: https://issues.apache.org/jira/browse/HBASE-9703
 Project: HBase
  Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.98.0, 0.96.1

 Attachments: hbase-9703_v1.patch, hbase-9703_v3.patch


 At the end of integration tests, we are calling 
 DistributedCluster.restoreCluster() in case CM has killed nodes so that we 
 can leave the cluster in the same state that we have taken over. 
 However, if CM is not used in a test (for example ITLoadAndVerify), but some 
 regions servers die, or an external daemon kills the servers, we will still  
 try to restore at the end of the test which may or may not succeed (depending 
 on configuration, the region server going being unaccessible, etc. )
 We can do two things, either do a best effort restore cluster which will not 
 fail the test if there are any errors, or we can skip running restore if no 
 disruptive actions have taken place. 
 I am leaning towards the former one, since if an RS goes down with or w/o CM 
 due to bad disk etc., we cannot restore the cluster, but we should not fail 
 the test in this case. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9390) coprocessors observers are not called during a recovery with the new log replay algorithm

2013-10-03 Thread Devaraj Das (JIRA)


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

Devaraj Das updated HBASE-9390:
---

   Resolution: Fixed
Fix Version/s: 0.96.1
   0.96.0
   Status: Resolved  (was: Patch Available)

This has been committed.

 coprocessors observers are not called during a recovery with the new log 
 replay algorithm
 -

 Key: HBASE-9390
 URL: https://issues.apache.org/jira/browse/HBASE-9390
 Project: HBase
  Issue Type: Bug
  Components: Coprocessors, MTTR
Affects Versions: 0.95.2
Reporter: Nicolas Liochon
Assignee: Jeffrey Zhong
 Fix For: 0.96.0, 0.96.1

 Attachments: copro.patch, hbase-9390-part2.patch, 
 hbase-9390-part2-v2.patch, hbase-9390.patch, 
 hbase-9390-review-addendum.patch, hbase-9390-v2.patch


 See the patch to reproduce the issue: If we activate log replay we don't have 
 the events on WAL restore.
 Pinging [~jeffreyz], we discussed this offline.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9703) DistributedHBaseCluster should not throw exceptions, but do a best effort restore


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

Enis Soztutar updated HBASE-9703:
-

   Resolution: Fixed
Fix Version/s: (was: 0.96.1)
   0.96.0
 Hadoop Flags: Reviewed
   Status: Resolved  (was: Patch Available)

I've committed this. Thanks for looking Sergey. 

 DistributedHBaseCluster should not throw exceptions, but do a best effort 
 restore
 -

 Key: HBASE-9703
 URL: https://issues.apache.org/jira/browse/HBASE-9703
 Project: HBase
  Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9703_v1.patch, hbase-9703_v3.patch


 At the end of integration tests, we are calling 
 DistributedCluster.restoreCluster() in case CM has killed nodes so that we 
 can leave the cluster in the same state that we have taken over. 
 However, if CM is not used in a test (for example ITLoadAndVerify), but some 
 regions servers die, or an external daemon kills the servers, we will still  
 try to restore at the end of the test which may or may not succeed (depending 
 on configuration, the region server going being unaccessible, etc. )
 We can do two things, either do a best effort restore cluster which will not 
 fail the test if there are any errors, or we can skip running restore if no 
 disruptive actions have taken place. 
 I am leaning towards the former one, since if an RS goes down with or w/o CM 
 due to bad disk etc., we cannot restore the cluster, but we should not fail 
 the test in this case. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9693) Fix javadoc warnings


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

Hudson commented on HBASE-9693:
---

FAILURE: Integrated in hbase-0.96-hadoop2 #73 (See 
[https://builds.apache.org/job/hbase-0.96-hadoop2/73/])
HBASE-9693 Fix javadoc warnings (jxiang: rev 1528944)
* 
/hbase/branches/0.96/hbase-client/src/main/java/org/apache/hadoop/hbase/catalog/MetaReader.java
* 
/hbase/branches/0.96/hbase-common/src/main/java/org/apache/hadoop/hbase/io/compress/Compression.java
* 
/hbase/branches/0.96/hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/executor/EventHandler.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/io/Reference.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFile.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/bucket/BucketCache.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/migration/UpgradeTo96.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/procedure/ProcedureCoordinator.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogSplitter.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/TableAuthManager.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HFileV1Detector.java
* 
/hbase/branches/0.96/hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftServerRunner.java


 Fix javadoc warnings
 

 Key: HBASE-9693
 URL: https://issues.apache.org/jira/browse/HBASE-9693
 Project: HBase
  Issue Type: Task
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Fix For: 0.98.0, 0.96.0

 Attachments: trunk-9693.patch


 There are not many javadoc warnings.  We can fix them all.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9686) More temporary test files are being left in /tmp/hbase-user


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

Hudson commented on HBASE-9686:
---

FAILURE: Integrated in hbase-0.96-hadoop2 #73 (See 
[https://builds.apache.org/job/hbase-0.96-hadoop2/73/])
HBASE-9686 More temporary test files are being left in /tmp/hbase-user 
(jmhsieh: rev 1528985)
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestCase.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestScannerSelectionUsingTTL.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/master/handler/TestTableDescriptorModification.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestAtomicOperation.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCacheOnWriteInSchema.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompaction.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionBusyWait.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestParallelPut.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessControlFilter.java


 More temporary test files are being left in /tmp/hbase-user
 -

 Key: HBASE-9686
 URL: https://issues.apache.org/jira/browse/HBASE-9686
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.96.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9686.patch, hbase-9686.v2.patch


 There is currently about 160MB of stuff being left behind in after a unit 
 test run in our jenkins setup.
 Table names left behind indicate that it is due to these classes.
 TestCompaction
 Either TestForceCacheImporatntBlocks or TestScannerSelectionUingTTL or 
 TestScannerSelectionUsingKeyRange
 TestHRegion



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9698) HBCK does not handle tables with no regions left


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

Hudson commented on HBASE-9698:
---

FAILURE: Integrated in hbase-0.96-hadoop2 #73 (See 
[https://builds.apache.org/job/hbase-0.96-hadoop2/73/])
HBASE-9698 HBCK does not handle tables with no regions left (enis: rev 1528991)
* 
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsck.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/util/hbck/TestOfflineMetaRebuildHole.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/util/hbck/TestOfflineMetaRebuildOverlap.java


 HBCK does not handle tables with no regions left
 

 Key: HBASE-9698
 URL: https://issues.apache.org/jira/browse/HBASE-9698
 Project: HBase
  Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9698_v1.patch, hbase-9698_v2.patch


 hbck does not handle the case where all the regions of a table is gone. To 
 reproduce this: 
 1. create table with one region 
 2. delete the region directory
 3. run hbck --repair, which removes the region from meta as well 
 4. now, the meta won't contain the region, but the table dir in hdfs will be 
 there. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9709) LogReplay throws NPE when no KVs to be replayed in a WALEdit


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

Jeffrey Zhong updated HBASE-9709:
-

Attachment: hbase-9709.patch

 LogReplay throws NPE when no KVs to be replayed in a WALEdit
 

 Key: HBASE-9709
 URL: https://issues.apache.org/jira/browse/HBASE-9709
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0
Reporter: Jeffrey Zhong
Assignee: Jeffrey Zhong
Priority: Minor
 Attachments: hbase-9709.patch


 This is regression from my recent checkin from hbase-9390 below is the 
 exception stack:
 {code}
 2013-10-03 09:34:32,735 ERROR [WriterThread-1] wal.HLogSplitter: Exiting 
 thread
 java.lang.NullPointerException
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$LogReplayOutputSink.groupEditsByServer(HLogSplitter.java:1489)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$LogReplayOutputSink.append(HLogSplitter.java:1368)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.writeBuffer(HLogSplitter.java:847)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.doRun(HLogSplitter.java:839)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.run(HLogSplitter.java:809)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9709) LogReplay throws NPE when no KVs to be replayed in a WALEdit


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

Jeffrey Zhong updated HBASE-9709:
-

Status: Patch Available  (was: Open)

 LogReplay throws NPE when no KVs to be replayed in a WALEdit
 

 Key: HBASE-9709
 URL: https://issues.apache.org/jira/browse/HBASE-9709
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0
Reporter: Jeffrey Zhong
Assignee: Jeffrey Zhong
Priority: Minor
 Attachments: hbase-9709.patch


 This is regression from my recent checkin from hbase-9390 below is the 
 exception stack:
 {code}
 2013-10-03 09:34:32,735 ERROR [WriterThread-1] wal.HLogSplitter: Exiting 
 thread
 java.lang.NullPointerException
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$LogReplayOutputSink.groupEditsByServer(HLogSplitter.java:1489)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$LogReplayOutputSink.append(HLogSplitter.java:1368)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.writeBuffer(HLogSplitter.java:847)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.doRun(HLogSplitter.java:839)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.run(HLogSplitter.java:809)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9709) LogReplay throws NPE when no KVs to be replayed in a WALEdit


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

Ted Yu commented on HBASE-9709:
---

+1

 LogReplay throws NPE when no KVs to be replayed in a WALEdit
 

 Key: HBASE-9709
 URL: https://issues.apache.org/jira/browse/HBASE-9709
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0
Reporter: Jeffrey Zhong
Assignee: Jeffrey Zhong
Priority: Minor
 Attachments: hbase-9709.patch


 This is regression from my recent checkin from hbase-9390 below is the 
 exception stack:
 {code}
 2013-10-03 09:34:32,735 ERROR [WriterThread-1] wal.HLogSplitter: Exiting 
 thread
 java.lang.NullPointerException
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$LogReplayOutputSink.groupEditsByServer(HLogSplitter.java:1489)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$LogReplayOutputSink.append(HLogSplitter.java:1368)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.writeBuffer(HLogSplitter.java:847)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.doRun(HLogSplitter.java:839)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.run(HLogSplitter.java:809)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9681) Basic codec negotiation

2013-10-03 Thread Andrew Purtell (JIRA)

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

Andrew Purtell commented on HBASE-9681:
---

bq. That sounds like a lot of round trips. Can we have the client send a
preference ordered list of codec it wants.

Basic codec negotiation
---

Key: HBASE-9681
URL: https://issues.apache.org/jira/browse/HBASE-9681
Project: HBase
Issue Type: Sub-task
Affects Versions: 0.98.0
Reporter: Andrew Purtell

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9709) LogReplay throws NPE when no KVs to be replayed in a WALEdit


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

Hadoop QA commented on HBASE-9709:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12606708/hbase-9709.patch
  against trunk revision .

{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 hadoop1.0{color}.  The patch compiles against the hadoop 
1.0 profile.

{color:green}+1 hadoop2.0{color}.  The patch compiles against the hadoop 
2.0 profile.

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

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

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) 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:red}-1 site{color}.  The patch appears to cause mvn site goal to 
fail.

{color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7462//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7462//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7462//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7462//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7462//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7462//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7462//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7462//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7462//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7462//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/7462//console

This message is automatically generated.

 LogReplay throws NPE when no KVs to be replayed in a WALEdit
 

 Key: HBASE-9709
 URL: https://issues.apache.org/jira/browse/HBASE-9709
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0
Reporter: Jeffrey Zhong
Assignee: Jeffrey Zhong
Priority: Minor
 Attachments: hbase-9709.patch


 This is regression from my recent checkin from hbase-9390 below is the 
 exception stack:
 {code}
 2013-10-03 09:34:32,735 ERROR [WriterThread-1] wal.HLogSplitter: Exiting 
 thread
 java.lang.NullPointerException
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$LogReplayOutputSink.groupEditsByServer(HLogSplitter.java:1489)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$LogReplayOutputSink.append(HLogSplitter.java:1368)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.writeBuffer(HLogSplitter.java:847)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.doRun(HLogSplitter.java:839)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.run(HLogSplitter.java:809)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9703) DistributedHBaseCluster should not throw exceptions, but do a best effort restore


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

Hudson commented on HBASE-9703:
---

FAILURE: Integrated in hbase-0.96 #122 (See 
[https://builds.apache.org/job/hbase-0.96/122/])
HBASE-9703 DistributedHBaseCluster should not throw exceptions, but do a best 
effort restore (enis: rev 1529046)
* 
/hbase/branches/0.96/hbase-it/src/test/java/org/apache/hadoop/hbase/DistributedHBaseCluster.java
* 
/hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseCluster.java


 DistributedHBaseCluster should not throw exceptions, but do a best effort 
 restore
 -

 Key: HBASE-9703
 URL: https://issues.apache.org/jira/browse/HBASE-9703
 Project: HBase
  Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9703_v1.patch, hbase-9703_v3.patch


 At the end of integration tests, we are calling 
 DistributedCluster.restoreCluster() in case CM has killed nodes so that we 
 can leave the cluster in the same state that we have taken over. 
 However, if CM is not used in a test (for example ITLoadAndVerify), but some 
 regions servers die, or an external daemon kills the servers, we will still  
 try to restore at the end of the test which may or may not succeed (depending 
 on configuration, the region server going being unaccessible, etc. )
 We can do two things, either do a best effort restore cluster which will not 
 fail the test if there are any errors, or we can skip running restore if no 
 disruptive actions have taken place. 
 I am leaning towards the former one, since if an RS goes down with or w/o CM 
 due to bad disk etc., we cannot restore the cluster, but we should not fail 
 the test in this case. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (HBASE-9703) DistributedHBaseCluster should not throw exceptions, but do a best effort restore


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

Hudson commented on HBASE-9703:
---

FAILURE: Integrated in HBase-TRUNK #4590 (See 
[https://builds.apache.org/job/HBase-TRUNK/4590/])
HBASE-9703 DistributedHBaseCluster should not throw exceptions, but do a best 
effort restore (enis: rev 1529045)
* 
/hbase/trunk/hbase-it/src/test/java/org/apache/hadoop/hbase/DistributedHBaseCluster.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseCluster.java


 DistributedHBaseCluster should not throw exceptions, but do a best effort 
 restore
 -

 Key: HBASE-9703
 URL: https://issues.apache.org/jira/browse/HBASE-9703
 Project: HBase
  Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.98.0, 0.96.0

 Attachments: hbase-9703_v1.patch, hbase-9703_v3.patch


 At the end of integration tests, we are calling 
 DistributedCluster.restoreCluster() in case CM has killed nodes so that we 
 can leave the cluster in the same state that we have taken over. 
 However, if CM is not used in a test (for example ITLoadAndVerify), but some 
 regions servers die, or an external daemon kills the servers, we will still  
 try to restore at the end of the test which may or may not succeed (depending 
 on configuration, the region server going being unaccessible, etc. )
 We can do two things, either do a best effort restore cluster which will not 
 fail the test if there are any errors, or we can skip running restore if no 
 disruptive actions have taken place. 
 I am leaning towards the former one, since if an RS goes down with or w/o CM 
 due to bad disk etc., we cannot restore the cluster, but we should not fail 
 the test in this case. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (HBASE-9706) Improve detection of secure ZooKeeper


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

Eric Yang reassigned HBASE-9706:


Assignee: Eric Yang

 Improve detection of secure ZooKeeper
 -

 Key: HBASE-9706
 URL: https://issues.apache.org/jira/browse/HBASE-9706
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.94.4, 0.95.0
 Environment: Java 6, RHEL, HBase 0.94.9
Reporter: Eric Yang
Assignee: Eric Yang
 Attachments: JIRA-9706-0.94.patch


 HBase client code assumes ZooKeeper is secured, as long as there is a 
 java.security.auth.login.config property being set.  When HBase client is 
 embedded in other java program with other security configuration, it can 
 produce wrong assumption that ZooKeeper is secured.  Ideally, 
 isSecureZooKeeper method should detect Jaas configuration specifically for 
 ZooKeeper to ensure that client program doesn't have a false positive 
 detection.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9706) Improve detection of secure ZooKeeper


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

Eric Yang updated HBASE-9706:
-

Attachment: JIRA-9706-0.94.patch

 Improve detection of secure ZooKeeper
 -

 Key: HBASE-9706
 URL: https://issues.apache.org/jira/browse/HBASE-9706
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.94.4, 0.95.0
 Environment: Java 6, RHEL, HBase 0.94.9
Reporter: Eric Yang
Assignee: Eric Yang
 Attachments: JIRA-9706-0.94.patch


 HBase client code assumes ZooKeeper is secured, as long as there is a 
 java.security.auth.login.config property being set.  When HBase client is 
 embedded in other java program with other security configuration, it can 
 produce wrong assumption that ZooKeeper is secured.  Ideally, 
 isSecureZooKeeper method should detect Jaas configuration specifically for 
 ZooKeeper to ensure that client program doesn't have a false positive 
 detection.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9706) Improve detection of secure ZooKeeper


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

Eric Yang updated HBASE-9706:
-

Attachment: JIRA-9706-0.95-trunk.patch

From 0.95 to trunk, the same patch applies.

 Improve detection of secure ZooKeeper
 -

 Key: HBASE-9706
 URL: https://issues.apache.org/jira/browse/HBASE-9706
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.94.4, 0.95.0
 Environment: Java 6, RHEL, HBase 0.94.9
Reporter: Eric Yang
Assignee: Eric Yang
 Attachments: JIRA-9706-0.94.patch, JIRA-9706-0.95-trunk.patch


 HBase client code assumes ZooKeeper is secured, as long as there is a 
 java.security.auth.login.config property being set.  When HBase client is 
 embedded in other java program with other security configuration, it can 
 produce wrong assumption that ZooKeeper is secured.  Ideally, 
 isSecureZooKeeper method should detect Jaas configuration specifically for 
 ZooKeeper to ensure that client program doesn't have a false positive 
 detection.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9706) Improve detection of secure ZooKeeper


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

Eric Yang updated HBASE-9706:
-

Status: Patch Available  (was: Open)

 Improve detection of secure ZooKeeper
 -

 Key: HBASE-9706
 URL: https://issues.apache.org/jira/browse/HBASE-9706
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.95.0, 0.94.4
 Environment: Java 6, RHEL, HBase 0.94.9
Reporter: Eric Yang
Assignee: Eric Yang
 Attachments: JIRA-9706-0.94.patch, JIRA-9706-0.95-trunk.patch


 HBase client code assumes ZooKeeper is secured, as long as there is a 
 java.security.auth.login.config property being set.  When HBase client is 
 embedded in other java program with other security configuration, it can 
 produce wrong assumption that ZooKeeper is secured.  Ideally, 
 isSecureZooKeeper method should detect Jaas configuration specifically for 
 ZooKeeper to ensure that client program doesn't have a false positive 
 detection.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (HBASE-9710) Use the region name, not the encoded name, in exceptions


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

Benoit Sigoure reassigned HBASE-9710:
-

Assignee: Benoit Sigoure

 Use the region name, not the encoded name, in exceptions
 

 Key: HBASE-9710
 URL: https://issues.apache.org/jira/browse/HBASE-9710
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 0.95.2, 0.96.0
Reporter: Benoit Sigoure
Assignee: Benoit Sigoure
Priority: Minor
 Attachments: 
 0001-Log-the-region-name-instead-of-the-encoded-region-na.patch


 When we throw a {{RegionOpeningException}} or a {{NotServingRegionException}} 
 we put the encoded region name in the exception, which isn't super useful.  I 
 propose putting the region name instead.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (HBASE-9710) Use the region name, not the encoded name, in exceptions

Benoit Sigoure created HBASE-9710:
-

 Summary: Use the region name, not the encoded name, in exceptions
 Key: HBASE-9710
 URL: https://issues.apache.org/jira/browse/HBASE-9710
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 0.95.2, 0.96.0
Reporter: Benoit Sigoure
Priority: Minor
 Attachments: 
0001-Log-the-region-name-instead-of-the-encoded-region-na.patch

When we throw a {{RegionOpeningException}} or a {{NotServingRegionException}} 
we put the encoded region name in the exception, which isn't super useful.  I 
propose putting the region name instead.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9710) Use the region name, not the encoded name, in exceptions


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

Benoit Sigoure updated HBASE-9710:
--

Status: Patch Available  (was: Open)

 Use the region name, not the encoded name, in exceptions
 

 Key: HBASE-9710
 URL: https://issues.apache.org/jira/browse/HBASE-9710
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 0.95.2, 0.96.0
Reporter: Benoit Sigoure
Assignee: Benoit Sigoure
Priority: Minor
 Attachments: 
 0001-Log-the-region-name-instead-of-the-encoded-region-na.patch


 When we throw a {{RegionOpeningException}} or a {{NotServingRegionException}} 
 we put the encoded region name in the exception, which isn't super useful.  I 
 propose putting the region name instead.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (HBASE-9710) Use the region name, not the encoded name, in exceptions