date:20140313


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

Hadoop QA commented on HBASE-9004:
--

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

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

{color:green}+0 tests included{color}.  The patch appears to be a 
documentation patch that doesn't require tests.

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

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

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 2 
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:green}+1 site{color}.  The mvn site goal succeeds with this patch.

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
   org.apache.hadoop.hbase.client.TestHCM

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

This message is automatically generated.

 Fix Documentation around Minor compaction and ttl
 -

 Key: HBASE-9004
 URL: https://issues.apache.org/jira/browse/HBASE-9004
 Project: HBase
  Issue Type: Task
  Components: documentation
Reporter: Elliott Clark
Assignee: Masatake Iwasaki
 Attachments: HBASE-9004-0.patch, HBASE-9004-1.patch


 Minor compactions should be able to delete KeyValues outside of ttl.  The 
 docs currently suggest otherwise.  We should bring them in line.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10549) When there is a hole, LoadIncrementalHFiles will hang in an infinite loop.


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

rajeshbabu updated HBASE-10549:
---

Fix Version/s: 0.98.2
   0.94.18
   0.99.0
   0.96.2

 When there is a hole, LoadIncrementalHFiles will hang in an infinite loop.
 --

 Key: HBASE-10549
 URL: https://issues.apache.org/jira/browse/HBASE-10549
 Project: HBase
  Issue Type: Bug
  Components: HFile
Affects Versions: 0.98.0, 0.94.11, 0.96.1.1
Reporter: yuanxinen
Assignee: yuanxinen
 Fix For: 0.96.2, 0.99.0, 0.94.18, 0.98.2

 Attachments: HBASE-10549-trunk-2014-03-13.patch, 
 HBASE-10549-trunk.patch


 First,I explan my test steps.
 1.importtsv
 2.split the region
 3.delete the region info from .META.(make a hole)
 4.LoadIncrementalHFiles (this step will hung up in an infinite loop)
 I check the log,there are two issues
 1.it create _tmp folder in an infinite loop.
 hdfs://hacluster/output3/i/_tmp/_tmp/_tmp/_tmp/_tmp/_tmp/test_table,136.bottom
 2.when slpliting the hfile,it put the first line data(1211) into two 
 files(top and bottom)
 Input 
 File=hdfs://hacluster/output3/i/3ac6ec287c644a8fb72d96b13e31f576,outFile=hdfs://hacluster/output3/i/_tmp/test_table,2.top,KeyValue=1211/i:value/1390469306407/Put/vlen=1/ts=0
 Input 
 File=hdfs://hacluster/output3/i/3ac6ec287c644a8fb72d96b13e31f576,outFile=hdfs://hacluster/output3/i/_tmp/test_table,2.bottom,KeyValue=1211/i:value/1390469306407/Put/vlen=1/ts=0
 and then I check the code.
 So I think before spliting the hfile,we should check the consistency of 
 startkey and endkey,if something wrong,we should throw the exception,and stop 
 LoadIncrementalHFiles.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10701) Cache invalidation improvements from client side

2014-03-13 Thread Nicolas Liochon (JIRA)


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

Nicolas Liochon commented on HBASE-10701:
-

bq. So locateRegionInMeta() call MIGHT return HRL
Hum, then we can have an issue here I think

{code}
  private RegionLocations findDestLocation(
  TableName tableName, Row row, boolean checkPrimary) throws IOException {
if (row == null) throw new IllegalArgumentException(# + id + , row 
cannot be null);
RegionLocations loc = hConnection.locateRegionAll(tableName, row.getRow());
if (loc == null
|| (checkPrimary  (loc.isEmpty()
|| loc.getDefaultRegionLocation() == null
|| loc.getDefaultRegionLocation().getServerName() == null))) {
  throw new IOException(# + id + , no location found, aborting submit 
for +
   tableName= + tableName +  rowkey= + 
Arrays.toString(row.getRow()));
}
return loc;
  }
{code}

The cache might return something with a null server name, w/o retrying to go to 
meta. The caller will get the exception, and will think after a lot of retry 
we can't get the location, so we're bad, so we stop
I'm not totally sure I'm right, because we're not looking for the secondary 
replicas here.

bq. It is inside a while loop.
Not the first one for the main replica :-)

bq. But you agree with the RetriesExhausted to be tried on every server no 
matter what, right ? 
It so extreme that I don't really know. I suppose that whatever you do it's 
going to be difficult at the end :-). I'm +1 whatever the final choice here.

 Cache invalidation improvements from client side
 

 Key: HBASE-10701
 URL: https://issues.apache.org/jira/browse/HBASE-10701
 Project: HBase
  Issue Type: Sub-task
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: hbase-10070

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


 Running the integration test in HBASE-10572, and HBASE-10355, it seems that 
 we need some changes for cache invalidation of meta entries from the client 
 side in backup RPCs. 
 Mainly the RPC's made for replicas should not invalidate the cache for all 
 the replicas (for example on RegionMovedException, connection error etc). 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-7847) Use zookeeper multi to clear znodes


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

Rakesh R updated HBASE-7847:


Attachment: HBASE-7847.patch

 Use zookeeper multi to clear znodes
 ---

 Key: HBASE-7847
 URL: https://issues.apache.org/jira/browse/HBASE-7847
 Project: HBase
  Issue Type: Sub-task
Reporter: Ted Yu
 Attachments: 7847-v1.txt, HBASE-7847.patch, HBASE-7847.patch


 In ZKProcedureUtil, clearChildZNodes() and clearZNodes(String procedureName) 
 should utilize zookeeper multi so that they're atomic



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-7847) Use zookeeper multi to clear znodes


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

Rakesh R commented on HBASE-7847:
-

Thank you Ted, Stack for the comments. Could you please have a look at the new 
patch.

Have made the following changes:
- Handled InterruptedException 
- Implemented the deleteChildrenRecursively api similar to the existing 
multiOrSequential api structure. Also, IMHO we can expose new util api 
ZKUtil#deleteChildrenRecursivelyMultiOrSequential to everyone.

-Rakesh

 Use zookeeper multi to clear znodes
 ---

 Key: HBASE-7847
 URL: https://issues.apache.org/jira/browse/HBASE-7847
 Project: HBase
  Issue Type: Sub-task
Reporter: Ted Yu
 Attachments: 7847-v1.txt, HBASE-7847.patch, HBASE-7847.patch


 In ZKProcedureUtil, clearChildZNodes() and clearZNodes(String procedureName) 
 should utilize zookeeper multi so that they're atomic



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10531) Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo

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

ramkrishna.s.vasudevan commented on HBASE-10531:

bq.But I'd say KV methods should take KVs, not Cells? If it takes Cells, could
be comparing a non-KV and it could actually work? Is this what we want? Maybe
this is just uglyness left over from how KV has been used/abused up to this?
But I'm thinking these compares would be Cell compares out in a CellUtil or
CellCompare class?
See HBASE-10532. All the above compares have been moved over there. But for
this JIRA I have still maintained things as KVComparator. Did not want to
change the KVComparator part here. I could change that also and call CellUtil
or CellComparator. Let me see how to handle that here.

bq.Shouldn't this be unsupportedoperationexception in your new key only class?
I think yes. But I faced some issue, hence added it. Let me check it once
again in the next patch.

bq.Why we have to create new key when we pass to a comparator?
I will add suitable comments.
bq.Should it be an offset? We do this '0' in a few places.
Where ever offset is needed I have used that. whereever 0 is needed I have used
0. I can cross check once again.
bq.So, this is the replacement: seekToKeyInBlock ? Purge the old stuff
I did not do that just for sake of easy review. Will purge all the duplicate
code.
bq.{ The array of byte arrays has Cells in it or it seems KVs? Will it always
be arrays of byte arrays?
I would suggest in the follow up JIRAs we can change to Cells? rather than
byte[]

All the last comments are about the refactoring part. I have not removed the
old code and hence you say them. I can remove them too. testReseek() i will
change to work with Cells, but thing to be noted is that previously it was
working with RawBytecomparator, am planning to change to KVComparator only.
Same with TestSeekTo.

Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo

Key: HBASE-10531
URL: https://issues.apache.org/jira/browse/HBASE-10531
Project: HBase
Issue Type: Sub-task
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
Fix For: 0.99.0

Attachments: HBASE-10531.patch, HBASE-10531_1.patch,
HBASE-10531_2.patch

Currently the byte[] key passed to HFileScanner.seekTo and
HFileScanner.reseekTo, is a combination of row, cf, qual, type and ts. And
the caller forms this by using kv.getBuffer, which is actually deprecated.
So see how this can be achieved considering kv.getBuffer is removed.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10531) Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo


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

ramkrishna.s.vasudevan commented on HBASE-10531:


Thanks for the review Stack.  I have an rb link also, which would help to 
review better.  Will keep updating my patch over there too.
https://reviews.apache.org/r/18570/

Let me come up with a complete micro benchmark after updating the comments and 
remvoing the duplicate code.

 Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo
 

 Key: HBASE-10531
 URL: https://issues.apache.org/jira/browse/HBASE-10531
 Project: HBase
  Issue Type: Sub-task
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 0.99.0

 Attachments: HBASE-10531.patch, HBASE-10531_1.patch, 
 HBASE-10531_2.patch


 Currently the byte[] key passed to HFileScanner.seekTo and 
 HFileScanner.reseekTo, is a combination of row, cf, qual, type and ts.  And 
 the caller forms this by using kv.getBuffer, which is actually deprecated.  
 So see how this can be achieved considering kv.getBuffer is removed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-9800) Impl CoprocessorRowcounter to run in command-line

2014-03-13 Thread chendihao (JIRA)


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

chendihao commented on HBASE-9800:
--

Thank [~yuzhih...@gmail.com] for reviewing.

1. I will update the license header.
2. LocalFileSink can be used when we set coprocessor.rowcounter.sink as 
org.apache.hadoop.hbase.coprocessor.example.CoprocessorRowcounter$LocalFileSink
 in the configuration file.
3. We periodically count the rows, so we need to indicate the date of the data. 
It's not so general but meets our requirements.
4. The patch for trunk will be uploaded later if we need it.

 Impl CoprocessorRowcounter to run in command-line
 -

 Key: HBASE-9800
 URL: https://issues.apache.org/jira/browse/HBASE-9800
 Project: HBase
  Issue Type: New Feature
  Components: Coprocessors
Affects Versions: 0.94.3
Reporter: chendihao
Assignee: chendihao
Priority: Minor
 Attachments: HBASE-9800-0.94-v1.patch


 We want to count the rows of table daily but the default rowcounter using 
 mapreduce is inefficient. Impl rowcounter using coprocessor makes it better. 
 Furthermore, It must provide the mechanism to choose the way to output result.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-1734) Priority queue sorted replication policy

2014-03-13 Thread Alvaro Garcia Recuero (JIRA)


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

Alvaro Garcia Recuero commented on HBASE-1734:
--

Here is my proposal [~apurtell]: 
https://docs.google.com/document/d/1xFEDykLcNVWrfPIWeDycvZ44eMpXGioZ4B7fP3Bl0rE/edit?usp=sharing.
 If validated I will upload here the design doc later. Will post further 
information soon from my side. Thank you.

 Priority queue sorted replication policy
 

 Key: HBASE-1734
 URL: https://issues.apache.org/jira/browse/HBASE-1734
 Project: HBase
  Issue Type: New Feature
  Components: Replication
Reporter: Andrew Purtell

 Implement a multi-level priority queue sorted replication policy which plugs 
 into the replication framework (HBASE-1733). Split incoming logs. Sort 
 outbound edits by priority. One option is to consider each column family's 
 replication policy tag as an index into a deadline table for EDF scheduling 
 (http://en.wikipedia.org/wiki/Earliest_deadline_first_scheduling). 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10549) When there is a hole, LoadIncrementalHFiles will hang in an infinite loop.


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

Hadoop QA commented on HBASE-10549:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12634383/HBASE-10549-trunk-2014-03-13.patch
  against trunk revision .
  ATTACHMENT ID: 12634383

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

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

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

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

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 2 
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:green}+1 site{color}.  The mvn site goal succeeds with this patch.

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

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

This message is automatically generated.

 When there is a hole, LoadIncrementalHFiles will hang in an infinite loop.
 --

 Key: HBASE-10549
 URL: https://issues.apache.org/jira/browse/HBASE-10549
 Project: HBase
  Issue Type: Bug
  Components: HFile
Affects Versions: 0.98.0, 0.94.11, 0.96.1.1
Reporter: yuanxinen
Assignee: yuanxinen
 Fix For: 0.96.2, 0.99.0, 0.94.18, 0.98.2

 Attachments: HBASE-10549-trunk-2014-03-13.patch, 
 HBASE-10549-trunk.patch


 First,I explan my test steps.
 1.importtsv
 2.split the region
 3.delete the region info from .META.(make a hole)
 4.LoadIncrementalHFiles (this step will hung up in an infinite loop)
 I check the log,there are two issues
 1.it create _tmp folder in an infinite loop.
 hdfs://hacluster/output3/i/_tmp/_tmp/_tmp/_tmp/_tmp/_tmp/test_table,136.bottom
 2.when slpliting the hfile,it put the first line data(1211) into two 
 files(top and bottom)
 Input 
 File=hdfs://hacluster/output3/i/3ac6ec287c644a8fb72d96b13e31f576,outFile=hdfs://hacluster/output3/i/_tmp/test_table,2.top,KeyValue=1211/i:value/1390469306407/Put/vlen=1/ts=0
 Input 
 File=hdfs://hacluster/output3/i/3ac6ec287c644a8fb72d96b13e31f576,outFile=hdfs://hacluster/output3/i/_tmp/test_table,2.bottom,KeyValue=1211/i:value/1390469306407/Put/vlen=1/ts=0
 and then I check the code.
 So I think before spliting the hfile,we should check the consistency of 
 startkey and endkey,if something wrong,we should throw the exception,and stop 
 LoadIncrementalHFiles.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10531) Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo


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

ramkrishna.s.vasudevan commented on HBASE-10531:


bq.The ByteBuffers here come from where?
It is already as per the existing logic.  
{code}
ByteBuffer buffer = block.getBufferWithoutHeader();
index = locateNonRootIndexEntry(buffer, key, comparator);
{code}

 Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo
 

 Key: HBASE-10531
 URL: https://issues.apache.org/jira/browse/HBASE-10531
 Project: HBase
  Issue Type: Sub-task
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 0.99.0

 Attachments: HBASE-10531.patch, HBASE-10531_1.patch, 
 HBASE-10531_2.patch


 Currently the byte[] key passed to HFileScanner.seekTo and 
 HFileScanner.reseekTo, is a combination of row, cf, qual, type and ts.  And 
 the caller forms this by using kv.getBuffer, which is actually deprecated.  
 So see how this can be achieved considering kv.getBuffer is removed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-7847) Use zookeeper multi to clear znodes


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

Hadoop QA commented on HBASE-7847:
--

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

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

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 2 
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:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+   * BFS Traversal of all the children under path, with the entries in the 
list, in the same order as
+   * Delete all the children of the specified nodes but not the nodes itself. 
Sets no watches. Throws

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

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

 {color:red}-1 core zombie tests{color}.  There are 1 zombie test(s):   
at 
org.apache.hadoop.hbase.regionserver.wal.TestLogRolling.testLogRollOnDatanodeDeath(TestLogRolling.java:368)

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

This message is automatically generated.

 Use zookeeper multi to clear znodes
 ---

 Key: HBASE-7847
 URL: https://issues.apache.org/jira/browse/HBASE-7847
 Project: HBase
  Issue Type: Sub-task
Reporter: Ted Yu
 Attachments: 7847-v1.txt, HBASE-7847.patch, HBASE-7847.patch


 In ZKProcedureUtil, clearChildZNodes() and clearZNodes(String procedureName) 
 should utilize zookeeper multi so that they're atomic



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10531) Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo


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

ramkrishna.s.vasudevan commented on HBASE-10531:


I think for now we need to add Cell comparison methods in KVComparator also, 
because we have lot of code internally that references this Kvcomparator and 
calls comparator.compareXXX().
So I would suggest we could make the change in using a CellComparator in 
another JIRA.  If not for now I will do this
{code}
protected int compareRowKey(final Cell left, final Cell right) {
  CellComparator.compareRows(left, right);
}
{code}

 Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo
 

 Key: HBASE-10531
 URL: https://issues.apache.org/jira/browse/HBASE-10531
 Project: HBase
  Issue Type: Sub-task
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 0.99.0

 Attachments: HBASE-10531.patch, HBASE-10531_1.patch, 
 HBASE-10531_2.patch


 Currently the byte[] key passed to HFileScanner.seekTo and 
 HFileScanner.reseekTo, is a combination of row, cf, qual, type and ts.  And 
 the caller forms this by using kv.getBuffer, which is actually deprecated.  
 So see how this can be achieved considering kv.getBuffer is removed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10531) Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo


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

ramkrishna.s.vasudevan commented on HBASE-10531:


Am also planning to remove the RawBytesComparator in all the testcases.  Once 
changing to cell this comparison may not work correctly.

 Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo
 

 Key: HBASE-10531
 URL: https://issues.apache.org/jira/browse/HBASE-10531
 Project: HBase
  Issue Type: Sub-task
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 0.99.0

 Attachments: HBASE-10531.patch, HBASE-10531_1.patch, 
 HBASE-10531_2.patch


 Currently the byte[] key passed to HFileScanner.seekTo and 
 HFileScanner.reseekTo, is a combination of row, cf, qual, type and ts.  And 
 the caller forms this by using kv.getBuffer, which is actually deprecated.  
 So see how this can be achieved considering kv.getBuffer is removed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-9800) Impl CoprocessorRowcounter to run in command-line

2014-03-13 Thread chendihao (JIRA)


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

chendihao updated HBASE-9800:
-

Attachment: HBASE-9800-0.94-v2.patch

patch for 0.94 v2

 Impl CoprocessorRowcounter to run in command-line
 -

 Key: HBASE-9800
 URL: https://issues.apache.org/jira/browse/HBASE-9800
 Project: HBase
  Issue Type: New Feature
  Components: Coprocessors
Affects Versions: 0.94.3
Reporter: chendihao
Assignee: chendihao
Priority: Minor
 Attachments: HBASE-9800-0.94-v1.patch, HBASE-9800-0.94-v2.patch


 We want to count the rows of table daily but the default rowcounter using 
 mapreduce is inefficient. Impl rowcounter using coprocessor makes it better. 
 Furthermore, It must provide the mechanism to choose the way to output result.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (HBASE-10736) Fix Javadoc warnings introduced in HBASE-10169

rajeshbabu created HBASE-10736:
--

 Summary: Fix Javadoc warnings introduced in HBASE-10169
 Key: HBASE-10736
 URL: https://issues.apache.org/jira/browse/HBASE-10736
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.98.0
Reporter: rajeshbabu
 Fix For: 0.98.1, 0.99.0


Fix below two javadoc warnings introduced as part of HBASE-10169
{code}

2 warnings

[WARNING] Javadoc Warnings

[WARNING] 
D:\D\hbaseCommunity\hbaseTrunkTest\hbase-client\src\main\java\org\apache\hadoop\hbase\client\RegionCoprocessorServiceExec.java:43:
 warning - Tag @link: can't find batchCoprocessorService(MethodDescriptor, 
Message, byte[], byte[],

[WARNING] Message, Batch.Callback) in org.apache.hadoop.hbase.client.HTable

[WARNING] 
D:\D\hbaseCommunity\hbaseTrunkTest\hbase-client\src\main\java\org\apache\hadoop\hbase\client\RegionCoprocessorServiceExec.java:43:
 warning - Tag @link: can't find batchCoprocessorService(MethodDescriptor, 
Message, byte[], byte[], Message) in org.apache.hadoop.hbase.client.HTable
{code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10549) When there is a hole, LoadIncrementalHFiles will hang in an infinite loop.


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

rajeshbabu commented on HBASE-10549:


+1

The javadoc warnings are not related to this issue(Raised HBASE-10736 to fix 
them).
[~Auraro] Please make patch for 0.94 also.
Thanks for working on this.



 When there is a hole, LoadIncrementalHFiles will hang in an infinite loop.
 --

 Key: HBASE-10549
 URL: https://issues.apache.org/jira/browse/HBASE-10549
 Project: HBase
  Issue Type: Bug
  Components: HFile
Affects Versions: 0.98.0, 0.94.11, 0.96.1.1
Reporter: yuanxinen
Assignee: yuanxinen
 Fix For: 0.96.2, 0.99.0, 0.94.18, 0.98.2

 Attachments: HBASE-10549-trunk-2014-03-13.patch, 
 HBASE-10549-trunk.patch


 First,I explan my test steps.
 1.importtsv
 2.split the region
 3.delete the region info from .META.(make a hole)
 4.LoadIncrementalHFiles (this step will hung up in an infinite loop)
 I check the log,there are two issues
 1.it create _tmp folder in an infinite loop.
 hdfs://hacluster/output3/i/_tmp/_tmp/_tmp/_tmp/_tmp/_tmp/test_table,136.bottom
 2.when slpliting the hfile,it put the first line data(1211) into two 
 files(top and bottom)
 Input 
 File=hdfs://hacluster/output3/i/3ac6ec287c644a8fb72d96b13e31f576,outFile=hdfs://hacluster/output3/i/_tmp/test_table,2.top,KeyValue=1211/i:value/1390469306407/Put/vlen=1/ts=0
 Input 
 File=hdfs://hacluster/output3/i/3ac6ec287c644a8fb72d96b13e31f576,outFile=hdfs://hacluster/output3/i/_tmp/test_table,2.bottom,KeyValue=1211/i:value/1390469306407/Put/vlen=1/ts=0
 and then I check the code.
 So I think before spliting the hfile,we should check the consistency of 
 startkey and endkey,if something wrong,we should throw the exception,and stop 
 LoadIncrementalHFiles.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-8963) Add configuration option to skip HFile archiving

2014-03-13 Thread bharath v (JIRA)


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

bharath v updated HBASE-8963:
-

Attachment: HBASE-8963.trunk.v1.patch

 Add configuration option to skip HFile archiving
 

 Key: HBASE-8963
 URL: https://issues.apache.org/jira/browse/HBASE-8963
 Project: HBase
  Issue Type: Improvement
Reporter: Ted Yu
Assignee: bharath v
 Attachments: HBASE-8963.trunk.v1.patch


 Currently HFileArchiver is always called when a table is dropped.
 A configuration option (either global or per table) should be provided so 
 that archiving can be skipped when table is deleted.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-8963) Add configuration option to skip HFile archiving

2014-03-13 Thread bharath v (JIRA)


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

bharath v updated HBASE-8963:
-

Status: Patch Available  (was: Open)

 Add configuration option to skip HFile archiving
 

 Key: HBASE-8963
 URL: https://issues.apache.org/jira/browse/HBASE-8963
 Project: HBase
  Issue Type: Improvement
Reporter: Ted Yu
Assignee: bharath v
 Attachments: HBASE-8963.trunk.v1.patch


 Currently HFileArchiver is always called when a table is dropped.
 A configuration option (either global or per table) should be provided so 
 that archiving can be skipped when table is deleted.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-5175) Add DoubleColumnInterpreter

2014-03-13 Thread Julian Wissmann (JIRA)


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

Julian Wissmann updated HBASE-5175:
---

Attachment: DoubleColumnInterpreter.patch

Patch created

 -Wrapped long lines
 -Fixed Comment in DoubleColumnInterpreter to reference correct test
 -Added License Headers

Are there any guidelines on formatting Protobuf autogenerated code, correctly? 
I autoindented that causing the patch to grow unnecessarily big.

 Add DoubleColumnInterpreter
 ---

 Key: HBASE-5175
 URL: https://issues.apache.org/jira/browse/HBASE-5175
 Project: HBase
  Issue Type: Sub-task
Reporter: Ted Yu
Assignee: Julian Wissmann
  Labels: aggregator, features
 Fix For: 0.99.0

 Attachments: DoubleColumnInterpreter.java, 
 DoubleColumnInterpreter.patch, HBase.proto, TestDoubleColumnInterpreter.java


 DoubleColumnInterpreter was requested by Royston Sellman.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-8963) Add configuration option to skip HFile archiving

2014-03-13 Thread Matteo Bertozzi (JIRA)


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

Matteo Bertozzi commented on HBASE-8963:


so, you are currently skipping the archive just for Delete Table? what about 
compactions and others?
I think that you should move the if (skipArchive) inside the archiver, since 
everyone is calling the archiver...
and the inside the archiver you check the skipArchive property.
In this way you don't have to put if (skipArchive) all around.

 Add configuration option to skip HFile archiving
 

 Key: HBASE-8963
 URL: https://issues.apache.org/jira/browse/HBASE-8963
 Project: HBase
  Issue Type: Improvement
Reporter: Ted Yu
Assignee: bharath v
 Attachments: HBASE-8963.trunk.v1.patch


 Currently HFileArchiver is always called when a table is dropped.
 A configuration option (either global or per table) should be provided so 
 that archiving can be skipped when table is deleted.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-7847) Use zookeeper multi to clear znodes


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

Rakesh R updated HBASE-7847:


Attachment: HBASE-7847.patch

 Use zookeeper multi to clear znodes
 ---

 Key: HBASE-7847
 URL: https://issues.apache.org/jira/browse/HBASE-7847
 Project: HBase
  Issue Type: Sub-task
Reporter: Ted Yu
 Attachments: 7847-v1.txt, HBASE-7847.patch, HBASE-7847.patch, 
 HBASE-7847.patch


 In ZKProcedureUtil, clearChildZNodes() and clearZNodes(String procedureName) 
 should utilize zookeeper multi so that they're atomic



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-7847) Use zookeeper multi to clear znodes


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

Rakesh R commented on HBASE-7847:
-

Attached one more patch where I have,
- included few tests 
- corrected '-1 lineLengths'

I failed to get the javadocs  test failure problems, is that related to my 
patch ?

 Use zookeeper multi to clear znodes
 ---

 Key: HBASE-7847
 URL: https://issues.apache.org/jira/browse/HBASE-7847
 Project: HBase
  Issue Type: Sub-task
Reporter: Ted Yu
 Attachments: 7847-v1.txt, HBASE-7847.patch, HBASE-7847.patch, 
 HBASE-7847.patch


 In ZKProcedureUtil, clearChildZNodes() and clearZNodes(String procedureName) 
 should utilize zookeeper multi so that they're atomic



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-8963) Add configuration option to skip HFile archiving


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

Hadoop QA commented on HBASE-8963:
--

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

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

{color:green}+1 tests included{color}.  The patch appears to include 2 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/8968//console

This message is automatically generated.

 Add configuration option to skip HFile archiving
 

 Key: HBASE-8963
 URL: https://issues.apache.org/jira/browse/HBASE-8963
 Project: HBase
  Issue Type: Improvement
Reporter: Ted Yu
Assignee: bharath v
 Attachments: HBASE-8963.trunk.v1.patch


 Currently HFileArchiver is always called when a table is dropped.
 A configuration option (either global or per table) should be provided so 
 that archiving can be skipped when table is deleted.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10549) When there is a hole, LoadIncrementalHFiles will hang in an infinite loop.

2014-03-13 Thread Ted Yu (JIRA)


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

Ted Yu commented on HBASE-10549:


+1

 When there is a hole, LoadIncrementalHFiles will hang in an infinite loop.
 --

 Key: HBASE-10549
 URL: https://issues.apache.org/jira/browse/HBASE-10549
 Project: HBase
  Issue Type: Bug
  Components: HFile
Affects Versions: 0.98.0, 0.94.11, 0.96.1.1
Reporter: yuanxinen
Assignee: yuanxinen
 Fix For: 0.96.2, 0.99.0, 0.94.18, 0.98.2

 Attachments: HBASE-10549-trunk-2014-03-13.patch, 
 HBASE-10549-trunk.patch


 First,I explan my test steps.
 1.importtsv
 2.split the region
 3.delete the region info from .META.(make a hole)
 4.LoadIncrementalHFiles (this step will hung up in an infinite loop)
 I check the log,there are two issues
 1.it create _tmp folder in an infinite loop.
 hdfs://hacluster/output3/i/_tmp/_tmp/_tmp/_tmp/_tmp/_tmp/test_table,136.bottom
 2.when slpliting the hfile,it put the first line data(1211) into two 
 files(top and bottom)
 Input 
 File=hdfs://hacluster/output3/i/3ac6ec287c644a8fb72d96b13e31f576,outFile=hdfs://hacluster/output3/i/_tmp/test_table,2.top,KeyValue=1211/i:value/1390469306407/Put/vlen=1/ts=0
 Input 
 File=hdfs://hacluster/output3/i/3ac6ec287c644a8fb72d96b13e31f576,outFile=hdfs://hacluster/output3/i/_tmp/test_table,2.bottom,KeyValue=1211/i:value/1390469306407/Put/vlen=1/ts=0
 and then I check the code.
 So I think before spliting the hfile,we should check the consistency of 
 startkey and endkey,if something wrong,we should throw the exception,and stop 
 LoadIncrementalHFiles.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-7847) Use zookeeper multi to clear znodes


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

rajeshbabu commented on HBASE-7847:
---

Latest patch lgtm. Nice tests [~rakeshr].

 Use zookeeper multi to clear znodes
 ---

 Key: HBASE-7847
 URL: https://issues.apache.org/jira/browse/HBASE-7847
 Project: HBase
  Issue Type: Sub-task
Reporter: Ted Yu
 Attachments: 7847-v1.txt, HBASE-7847.patch, HBASE-7847.patch, 
 HBASE-7847.patch


 In ZKProcedureUtil, clearChildZNodes() and clearZNodes(String procedureName) 
 should utilize zookeeper multi so that they're atomic



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10549) When there is a hole, LoadIncrementalHFiles will hang in an infinite loop.


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

rajeshbabu commented on HBASE-10549:


I will commit it tomorrow If no objections.

 When there is a hole, LoadIncrementalHFiles will hang in an infinite loop.
 --

 Key: HBASE-10549
 URL: https://issues.apache.org/jira/browse/HBASE-10549
 Project: HBase
  Issue Type: Bug
  Components: HFile
Affects Versions: 0.98.0, 0.94.11, 0.96.1.1
Reporter: yuanxinen
Assignee: yuanxinen
 Fix For: 0.96.2, 0.99.0, 0.94.18, 0.98.2

 Attachments: HBASE-10549-trunk-2014-03-13.patch, 
 HBASE-10549-trunk.patch


 First,I explan my test steps.
 1.importtsv
 2.split the region
 3.delete the region info from .META.(make a hole)
 4.LoadIncrementalHFiles (this step will hung up in an infinite loop)
 I check the log,there are two issues
 1.it create _tmp folder in an infinite loop.
 hdfs://hacluster/output3/i/_tmp/_tmp/_tmp/_tmp/_tmp/_tmp/test_table,136.bottom
 2.when slpliting the hfile,it put the first line data(1211) into two 
 files(top and bottom)
 Input 
 File=hdfs://hacluster/output3/i/3ac6ec287c644a8fb72d96b13e31f576,outFile=hdfs://hacluster/output3/i/_tmp/test_table,2.top,KeyValue=1211/i:value/1390469306407/Put/vlen=1/ts=0
 Input 
 File=hdfs://hacluster/output3/i/3ac6ec287c644a8fb72d96b13e31f576,outFile=hdfs://hacluster/output3/i/_tmp/test_table,2.bottom,KeyValue=1211/i:value/1390469306407/Put/vlen=1/ts=0
 and then I check the code.
 So I think before spliting the hfile,we should check the consistency of 
 startkey and endkey,if something wrong,we should throw the exception,and stop 
 LoadIncrementalHFiles.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-8963) Add configuration option to skip HFile archiving

2014-03-13 Thread bharath v (JIRA)


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

bharath v commented on HBASE-8963:
--

 I wrote this patch just keeping the DeleteHandler in mind as I got confused by 
the jira description. It makes sense to move the skipArchive check to archiver 
makes more sense so that other components like compactors can use it too. Will 
upload a new patch with changes shortly. Thanks for your quick review 
[~mbertozzi].

 Add configuration option to skip HFile archiving
 

 Key: HBASE-8963
 URL: https://issues.apache.org/jira/browse/HBASE-8963
 Project: HBase
  Issue Type: Improvement
Reporter: Ted Yu
Assignee: bharath v
 Attachments: HBASE-8963.trunk.v1.patch


 Currently HFileArchiver is always called when a table is dropped.
 A configuration option (either global or per table) should be provided so 
 that archiving can be skipped when table is deleted.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-9800) Impl CoprocessorRowcounter to run in command-line

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

Hadoop QA commented on HBASE-9800:
--

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment

http://issues.apache.org/jira/secure/attachment/12634418/HBASE-9800-0.94-v2.patch
against trunk revision .
ATTACHMENT ID: 12634418

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

{color:red}-1 javadoc{color}. The javadoc tool appears to have generated 2
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:green}+1 site{color}. The mvn site goal succeeds with this patch.

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

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

This message is automatically generated.

Impl CoprocessorRowcounter to run in command-line
-

Key: HBASE-9800
URL: https://issues.apache.org/jira/browse/HBASE-9800
Project: HBase
Issue Type: New Feature
Components: Coprocessors
Affects Versions: 0.94.3
Reporter: chendihao
Assignee: chendihao
Priority: Minor
Attachments: HBASE-9800-0.94-v1.patch, HBASE-9800-0.94-v2.patch

We want to count the rows of table daily but the default rowcounter using
mapreduce is inefficient. Impl rowcounter using coprocessor makes it better.
Furthermore, It must provide the mechanism to choose the way to output result.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-7847) Use zookeeper multi to clear znodes