date:20130124

[jira] [Commented] (HBASE-5843) Improve HBase MTTR - Mean Time To Recover

2013-01-24 Thread nkeywal (JIRA)

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

nkeywal commented on HBASE-5843:

Agreed, you need to be a kind of expert to make the difference between 'slow
for the moment' and 'broken because we have a bad internal state'. This said,
if the issue comes from a coprocessor bug, you just need to be an expert of
this coprocessor.

Likely, the number of threads/memory consumed/file descriptors/... could be
considered as indicators that something is going wrong, but it could be already
too late for a clean stop as well...

Improve HBase MTTR - Mean Time To Recover
-

Key: HBASE-5843
URL: https://issues.apache.org/jira/browse/HBASE-5843
Project: HBase
Issue Type: Umbrella
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal

A part of the approach is described here:
https://docs.google.com/document/d/1z03xRoZrIJmg7jsWuyKYl6zNournF_7ZHzdi0qz_B4c/edit
The ideal target is:
- failure impact client applications only by an added delay to execute a
query, whatever the failure.
- this delay is always inferior to 1 second.
We're not going to achieve that immediately...
Priority will be given to the most frequent issues.
Short term:
- software crash
- standard administrative tasks as stop/start of a cluster.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5930) Periodically flush the Memstore?

2013-01-24 Thread nkeywal (JIRA)

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

nkeywal commented on HBASE-5930:

bq. With this, maybe we will no longer need skipWAL if we can prove that
deferred flush is as fast as skip WAL.
In standard database, skipping the WAL is often used when you're doing a
functional upgrade requiring some unavailability time, i.e.:
- dump
- run batch scripts to update your data
- if anything goes wrong reload the dump

For hundreds of reasons it makes much less sense with HBase, but it could
happen (some companies don't need 24x24). So we should not remove the skipWAL
imho, except if it really simplify something internally.

On the patch itself, I have a question on adding some randomness. The scenario
I'm thinking about is a massive but periodic update on a table: all the regions
will be written simultaneously, hence flushed simultaneously. That's the main
use case for this JIRA, and this could hammer the namenode, imho. Except if we
thing there is enough randomness by having a different flusher by regionserver
(which may not be the case if all regions servers are started simultaneously).

As a side note, I would personally like a flush interval of 10 minutes:
- it would help on .META. recovery, especially with the separate wal for .META.
- this allows to have more regions: today, on average and in theory, each
region takes 50% of an hdfs block size of memory. The more regions we flush
early, the more empty memstore we have...

Periodically flush the Memstore?

Key: HBASE-5930
URL: https://issues.apache.org/jira/browse/HBASE-5930
Project: HBase
Issue Type: Improvement
Reporter: Lars Hofhansl
Assignee: Devaraj Das
Priority: Minor
Fix For: 0.96.0

Attachments: 5930-1.patch, 5930-wip.patch

A colleague of mine ran into an interesting issue.
He inserted some data with the WAL disabled, which happened to fit in the
aggregate Memstores memory.
Two weeks later he a had problem with the HDFS cluster, which caused the
region servers to abort. He found that his data was lost. Looking at the log
we found that the Memstores were not flushed at all during these two weeks.
Should we have an option to flush memstores periodically. There are obvious
downsides to this, like many small storefiles, etc.

[jira] [Commented] (HBASE-7643) HFileArchiver.resolveAndArchive() race condition may lead to snapshot data loss

2013-01-24 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on HBASE-7643:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12566268/HBASE-7653-p4-v6.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 3 new 
or modified tests.

{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 introduce 1 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 core tests{color}.  The patch passed unit tests in .

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

This message is automatically generated.

 HFileArchiver.resolveAndArchive() race condition may lead to snapshot data 
 loss
 ---

 Key: HBASE-7643
 URL: https://issues.apache.org/jira/browse/HBASE-7643
 Project: HBase
  Issue Type: Bug
Affects Versions: hbase-6055, 0.96.0
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Blocker
 Fix For: 0.96.0, 0.94.5

 Attachments: HBASE-7653-p4-v0.patch, HBASE-7653-p4-v1.patch, 
 HBASE-7653-p4-v2.patch, HBASE-7653-p4-v3.patch, HBASE-7653-p4-v4.patch, 
 HBASE-7653-p4-v5.patch, HBASE-7653-p4-v6.patch


  * The master have an hfile cleaner thread (that is responsible for cleaning 
 the /hbase/.archive dir)
  ** /hbase/.archive/table/region/family/hfile
  ** if the family/region/family directory is empty the cleaner removes it
  * The master can archive files (from another thread, e.g. DeleteTableHandler)
  * The region can archive files (from another server/process, e.g. compaction)
 The simplified file archiving code looks like this:
 {code}
 HFileArchiver.resolveAndArchive(...) {
   // ensure that the archive dir exists
   fs.mkdir(archiveDir);
   // move the file to the archiver
   success = fs.rename(originalPath/fileName, archiveDir/fileName)
   // if the rename is failed, delete the file without archiving
   if (!success) fs.delete(originalPath/fileName);
 }
 {code}
 Since there's no synchronization between HFileArchiver.resolveAndArchive() 
 and the cleaner run (different process, thread, ...) you can end up in the 
 situation where you are moving something in a directory that doesn't exists.
 {code}
 fs.mkdir(archiveDir);
 // HFileCleaner chore starts at this point
 // and the archiveDirectory that we just ensured to be present gets removed.
 // The rename at this point will fail since the parent directory is missing.
 success = fs.rename(originalPath/fileName, archiveDir/fileName)
 {code}
 The bad thing of deleting the file without archiving is that if you've a 
 snapshot that relies on the file to be present, or you've a clone table that 
 relies on that file is that you're losing data.
 Possible solutions
  * Create a ZooKeeper lock, to notify the master (Hey I'm archiving 
 something, wait a bit)
  * Add a RS - Master call to let the master removes files and avoid this 
 kind of situations
  * Avoid to remove empty directories from the archive if the table exists or 
 is not

[jira] [Updated] (HBASE-7495) parallel seek in StoreScanner

2013-01-24 Thread liang xie (JIRA)


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

liang xie updated HBASE-7495:
-

Attachment: HBASE-7495.txt

 parallel seek in StoreScanner
 -

 Key: HBASE-7495
 URL: https://issues.apache.org/jira/browse/HBASE-7495
 Project: HBase
  Issue Type: Bug
  Components: Scanners
Affects Versions: 0.94.3, 0.96.0
Reporter: liang xie
Assignee: liang xie
 Attachments: HBASE-7495.txt, HBASE-7495.txt, HBASE-7495.txt


 seems there's a potential improvable space before doing scanner.next:
 {code:title=StoreScanner.java|borderStyle=solid}
 if (explicitColumnQuery  lazySeekEnabledGlobally) {
   for (KeyValueScanner scanner : scanners) {
 scanner.requestSeek(matcher.getStartKey(), false, true);
   }
 } else {
   for (KeyValueScanner scanner : scanners) {
 scanner.seek(matcher.getStartKey());
   }
 }
 {code} 
 we can do scanner.requestSeek or scanner.seek in parallel, instead of current 
 serialization, to reduce latency for special case.
 Any ideas on it ?  I'll have a try if the comments/suggestions are positive：）

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-7653) scan CF in parallel

2013-01-24 Thread liang xie (JIRA)

liang xie created HBASE-7653:


 Summary: scan CF in parallel
 Key: HBASE-7653
 URL: https://issues.apache.org/jira/browse/HBASE-7653
 Project: HBase
  Issue Type: Improvement
  Components: regionserver
Affects Versions: 0.96.0
Reporter: liang xie
Assignee: liang xie


just placeholder, the idea comes from HBASE-7495, per lars' comments.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-7654) Add ListString getCoprocessors() to HTableInterface.

2013-01-24 Thread Jean-Marc Spaggiari (JIRA)

Jean-Marc Spaggiari created HBASE-7654:
--

 Summary: Add ListString getCoprocessors() to HTableInterface.
 Key: HBASE-7654
 URL: https://issues.apache.org/jira/browse/HBASE-7654
 Project: HBase
  Issue Type: Bug
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Critical


Add ListString getCoprocessors() to HTableInterface to retreive the list of 
coprocessors loaded into this table.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-7495) parallel seek in StoreScanner

2013-01-24 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on HBASE-7495:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12566294/HBASE-7495.txt
  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 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 introduce 1 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 core tests{color}.  The patch failed these unit tests:
   org.apache.hadoop.hbase.regionserver.TestHRegion
  org.apache.hadoop.hbase.regionserver.TestAtomicOperation
  org.apache.hadoop.hbase.TestAcidGuarantees
  org.apache.hadoop.hbase.regionserver.TestHRegionBusyWait

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

This message is automatically generated.

 parallel seek in StoreScanner
 -

 Key: HBASE-7495
 URL: https://issues.apache.org/jira/browse/HBASE-7495
 Project: HBase
  Issue Type: Bug
  Components: Scanners
Affects Versions: 0.94.3, 0.96.0
Reporter: liang xie
Assignee: liang xie
 Attachments: HBASE-7495.txt, HBASE-7495.txt, HBASE-7495.txt


 seems there's a potential improvable space before doing scanner.next:
 {code:title=StoreScanner.java|borderStyle=solid}
 if (explicitColumnQuery  lazySeekEnabledGlobally) {
   for (KeyValueScanner scanner : scanners) {
 scanner.requestSeek(matcher.getStartKey(), false, true);
   }
 } else {
   for (KeyValueScanner scanner : scanners) {
 scanner.seek(matcher.getStartKey());
   }
 }
 {code} 
 we can do scanner.requestSeek or scanner.seek in parallel, instead of current 
 serialization, to reduce latency for special case.
 Any ideas on it ?  I'll have a try if the comments/suggestions are positive：）

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-7654) Add ListString getCoprocessors() to HTableInterface.

2013-01-24 Thread Jean-Marc Spaggiari (JIRA)


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

Jean-Marc Spaggiari updated HBASE-7654:
---

Attachment: HBASE-7654-v0-trunk.patch

 Add ListString getCoprocessors() to HTableInterface.
 --

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


 Add ListString getCoprocessors() to HTableInterface to retreive the list of 
 coprocessors loaded into this table.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-7654) Add ListString getCoprocessors() to HTableInterface.

2013-01-24 Thread Jean-Marc Spaggiari (JIRA)


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

Jean-Marc Spaggiari updated HBASE-7654:
---

Status: Patch Available  (was: Open)

Pretty trivial patch to add ListString getCoprocessors() to HTableDescriptor. 
Also adding the related tests, and cleaning some extra non-required spaces.

 Add ListString getCoprocessors() to HTableInterface.
 --

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


 Add ListString getCoprocessors() to HTableInterface to retreive the list of 
 coprocessors loaded into this table.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-7634) Replication handling of changes to peer clusters is inefficient

2013-01-24 Thread Gabriel Reid (JIRA)


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

Gabriel Reid updated HBASE-7634:


Status: Patch Available  (was: Open)

 Replication handling of changes to peer clusters is inefficient
 ---

 Key: HBASE-7634
 URL: https://issues.apache.org/jira/browse/HBASE-7634
 Project: HBase
  Issue Type: Bug
  Components: Replication
Affects Versions: 0.96.0
Reporter: Gabriel Reid
 Attachments: HBASE-7634.patch


 The current handling of changes to the region servers in a replication peer 
 cluster is currently quite inefficient. The list of region servers that are 
 being replicated to is only updated if there are a large number of issues 
 encountered while replicating.
 This can cause it to take quite a while to recognize that a number of the 
 regionserver in a peer cluster are no longer available. A potentially bigger 
 problem is that if a replication peer cluster is started with a small number 
 of regionservers, and then more region servers are added after replication 
 has started, the additional region servers will never be used for replication 
 (unless there are failures on the in-use regionservers).
 Part of the current issue is that the retry code in 
 ReplicationSource#shipEdits checks a randomly-chosen replication peer 
 regionserver (in ReplicationSource#isSlaveDown) to see if it is up after a 
 replication write has failed on a different randonly-chosen replication peer. 
 If the peer is seen as not down, another randomly-chosen peer is used for 
 writing.
 A second part of the issue is that changes to the list of region servers in a 
 peer cluster are not detected at all, and are only picked up if a certain 
 number of failures have occurred when trying to ship edits.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-7654) Add ListString getCoprocessors() to HTableInterface.

2013-01-24 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on HBASE-7654:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12566301/HBASE-7654-v0-trunk.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 3 new 
or modified tests.

{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 introduce 1 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 core tests{color}.  The patch passed unit tests in .

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

This message is automatically generated.

 Add ListString getCoprocessors() to HTableInterface.
 --

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


 Add ListString getCoprocessors() to HTableInterface to retreive the list of 
 coprocessors loaded into this table.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-7634) Replication handling of changes to peer clusters is inefficient

2013-01-24 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-7634:
--

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12565799/HBASE-7634.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/4159//console

This message is automatically generated.

Replication handling of changes to peer clusters is inefficient
---

Key: HBASE-7634
URL: https://issues.apache.org/jira/browse/HBASE-7634
Project: HBase
Issue Type: Bug
Components: Replication
Affects Versions: 0.96.0
Reporter: Gabriel Reid
Attachments: HBASE-7634.patch

The current handling of changes to the region servers in a replication peer
cluster is currently quite inefficient. The list of region servers that are
being replicated to is only updated if there are a large number of issues
encountered while replicating.
This can cause it to take quite a while to recognize that a number of the
regionserver in a peer cluster are no longer available. A potentially bigger
problem is that if a replication peer cluster is started with a small number
of regionservers, and then more region servers are added after replication
has started, the additional region servers will never be used for replication
(unless there are failures on the in-use regionservers).
Part of the current issue is that the retry code in
ReplicationSource#shipEdits checks a randomly-chosen replication peer
regionserver (in ReplicationSource#isSlaveDown) to see if it is up after a
replication write has failed on a different randonly-chosen replication peer.
If the peer is seen as not down, another randomly-chosen peer is used for
writing.
A second part of the issue is that changes to the list of region servers in a
peer cluster are not detected at all, and are only picked up if a certain
number of failures have occurred when trying to ship edits.

[jira] [Updated] (HBASE-7651) RegionServerSnapshotManager fails with CancellationException if previous snapshot fails in per region task

2013-01-24 Thread Jonathan Hsieh (JIRA)


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

Jonathan Hsieh updated HBASE-7651:
--

Summary: RegionServerSnapshotManager fails with CancellationException if 
previous snapshot fails in per region task  (was: RegionServerSnapshotManager 
fails with CancellationException if previous fails with in per region task)

 RegionServerSnapshotManager fails with CancellationException if previous 
 snapshot fails in per region task
 --

 Key: HBASE-7651
 URL: https://issues.apache.org/jira/browse/HBASE-7651
 Project: HBase
  Issue Type: Sub-task
  Components: snapshots
Affects Versions: hbase-7290
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Priority: Blocker

 I've reproduced this problem consistently on a 20 node cluster.
 The first run fails on a node (jon-snaphots-2 in this case) to take snapshot 
 due to a NotServingRegionException (this is acceptable)
 {code}
 2013-01-23 13:32:48,631 DEBUG 
 org.apache.hadoop.hbase.errorhandling.ForeignExceptionDispatcher:  accepting 
 received exception
 org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable via 
 jon-snapshots-2.ent.cloudera.com,22101,1358976524369:org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable:
  org.apache.hadoop.hbase.NotServingRegionException: 
 TestTable,0002493652,1358976652443.b858147ad87a7812ac9a73dd8fef36ad. is 
 closing
 at 
 org.apache.hadoop.hbase.errorhandling.ForeignException.deserialize(ForeignException.java:184)
 at 
 org.apache.hadoop.hbase.procedure.ZKProcedureCoordinatorRpcs.abort(ZKProcedureCoordinatorRpcs.java:240)
 at 
 org.apache.hadoop.hbase.procedure.ZKProcedureCoordinatorRpcs$1.nodeCreated(ZKProcedureCoordinatorRpcs.java:182)
 at 
 org.apache.hadoop.hbase.zookeeper.ZooKeeperWatcher.process(ZooKeeperWatcher.java:294)
 at 
 org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:519)
 at 
 org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:495)
 Caused by: 
 org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable: 
 org.apache.hadoop.hbase.NotServingRegionException: 
 TestTable,0002493652,1358976652443.b858147ad87a7812ac9a73dd8fef36ad. is 
 closing
 at 
 org.apache.hadoop.hbase.regionserver.snapshot.RegionServerSnapshotManager$SnapshotSubprocedurePool.waitForOutstandingTasks(RegionServerSnapshotManager.java:343)
 at 
 org.apache.hadoop.hbase.regionserver.snapshot.FlushSnapshotSubprocedure.flushSnapshot(FlushSnapshotSubprocedure.java:107)
 at 
 org.apache.hadoop.hbase.regionserver.snapshot.FlushSnapshotSubprocedure.insideBarrier(FlushSnapshotSubprocedure.java:123)
 at 
 org.apache.hadoop.hbase.procedure.Subprocedure.call(Subprocedure.java:181)
 at 
 org.apache.hadoop.hbase.procedure.Subprocedure.call(Subprocedure.java:52)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 2013-01-23 13:32:48,631 DEBUG 
 org.apache.hadoop.hbase.errorhandling.ForeignExceptionDispatcher:  Recieved 
 error, notifying listeners...
 2013-01-23 13:32:48,730 ERROR org.apache.hadoop.hbase.procedure.Procedure: 
 Procedure 'pe-6' execution failed!
 org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable via 
 jon-snapshots-2.ent.cloudera.com,22101,1358976524369:org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable:
  org.apache.hadoop.hbase.NotServingRegionException: 
 TestTable,0002493652,1358976652443.b858147ad87a7812ac9a73dd8fef36ad. is 
 closing
 at 
 org.apache.hadoop.hbase.errorhandling.ForeignExceptionDispatcher.rethrowException(ForeignExceptionDispatcher.java:84)
 at 
 org.apache.hadoop.hbase.procedure.Procedure.waitForLatch(Procedure.java:357)
 at 
 org.apache.hadoop.hbase.procedure.Procedure.call(Procedure.java:203)
 at org.apache.hadoop.hbase.procedure.Procedure.call(Procedure.java:68)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 Caused by: 
 org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable:

[jira] [Updated] (HBASE-7651) RegionServerSnapshotManager fails with CancellationException if previous fails with in per region task

2013-01-24 Thread Jonathan Hsieh (JIRA)


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

Jonathan Hsieh updated HBASE-7651:
--

Summary: RegionServerSnapshotManager fails with CancellationException if 
previous fails with in per region task  (was: RegionServerSnapshotManager does 
not accept subsquent snapshots if previous fails with 
NotServingRegionException.)

 RegionServerSnapshotManager fails with CancellationException if previous 
 fails with in per region task
 --

 Key: HBASE-7651
 URL: https://issues.apache.org/jira/browse/HBASE-7651
 Project: HBase
  Issue Type: Sub-task
  Components: snapshots
Affects Versions: hbase-7290
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Priority: Blocker

 I've reproduced this problem consistently on a 20 node cluster.
 The first run fails on a node (jon-snaphots-2 in this case) to take snapshot 
 due to a NotServingRegionException (this is acceptable)
 {code}
 2013-01-23 13:32:48,631 DEBUG 
 org.apache.hadoop.hbase.errorhandling.ForeignExceptionDispatcher:  accepting 
 received exception
 org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable via 
 jon-snapshots-2.ent.cloudera.com,22101,1358976524369:org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable:
  org.apache.hadoop.hbase.NotServingRegionException: 
 TestTable,0002493652,1358976652443.b858147ad87a7812ac9a73dd8fef36ad. is 
 closing
 at 
 org.apache.hadoop.hbase.errorhandling.ForeignException.deserialize(ForeignException.java:184)
 at 
 org.apache.hadoop.hbase.procedure.ZKProcedureCoordinatorRpcs.abort(ZKProcedureCoordinatorRpcs.java:240)
 at 
 org.apache.hadoop.hbase.procedure.ZKProcedureCoordinatorRpcs$1.nodeCreated(ZKProcedureCoordinatorRpcs.java:182)
 at 
 org.apache.hadoop.hbase.zookeeper.ZooKeeperWatcher.process(ZooKeeperWatcher.java:294)
 at 
 org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:519)
 at 
 org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:495)
 Caused by: 
 org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable: 
 org.apache.hadoop.hbase.NotServingRegionException: 
 TestTable,0002493652,1358976652443.b858147ad87a7812ac9a73dd8fef36ad. is 
 closing
 at 
 org.apache.hadoop.hbase.regionserver.snapshot.RegionServerSnapshotManager$SnapshotSubprocedurePool.waitForOutstandingTasks(RegionServerSnapshotManager.java:343)
 at 
 org.apache.hadoop.hbase.regionserver.snapshot.FlushSnapshotSubprocedure.flushSnapshot(FlushSnapshotSubprocedure.java:107)
 at 
 org.apache.hadoop.hbase.regionserver.snapshot.FlushSnapshotSubprocedure.insideBarrier(FlushSnapshotSubprocedure.java:123)
 at 
 org.apache.hadoop.hbase.procedure.Subprocedure.call(Subprocedure.java:181)
 at 
 org.apache.hadoop.hbase.procedure.Subprocedure.call(Subprocedure.java:52)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 2013-01-23 13:32:48,631 DEBUG 
 org.apache.hadoop.hbase.errorhandling.ForeignExceptionDispatcher:  Recieved 
 error, notifying listeners...
 2013-01-23 13:32:48,730 ERROR org.apache.hadoop.hbase.procedure.Procedure: 
 Procedure 'pe-6' execution failed!
 org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable via 
 jon-snapshots-2.ent.cloudera.com,22101,1358976524369:org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable:
  org.apache.hadoop.hbase.NotServingRegionException: 
 TestTable,0002493652,1358976652443.b858147ad87a7812ac9a73dd8fef36ad. is 
 closing
 at 
 org.apache.hadoop.hbase.errorhandling.ForeignExceptionDispatcher.rethrowException(ForeignExceptionDispatcher.java:84)
 at 
 org.apache.hadoop.hbase.procedure.Procedure.waitForLatch(Procedure.java:357)
 at 
 org.apache.hadoop.hbase.procedure.Procedure.call(Procedure.java:203)
 at org.apache.hadoop.hbase.procedure.Procedure.call(Procedure.java:68)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 Caused by: 
 org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable:

[jira] [Updated] (HBASE-7503) Add exists(List) in HTableInterface to allow multiple parallel exists at one time

2013-01-24 Thread Jean-Marc Spaggiari (JIRA)


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

Jean-Marc Spaggiari updated HBASE-7503:
---

Status: Open  (was: Patch Available)

 Add exists(List) in HTableInterface to allow multiple parallel exists at one 
 time
 -

 Key: HBASE-7503
 URL: https://issues.apache.org/jira/browse/HBASE-7503
 Project: HBase
  Issue Type: Improvement
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-7503-v0-trunk.patch, HBASE-7503-v10-trunk.patch, 
 HBASE-7503-v11-trunk.patch, HBASE-7503-v12-trunk.patch, 
 HBASE-7503-v1-trunk.patch, HBASE-7503-v2-trunk.patch, 
 HBASE-7503-v2-trunk.patch, HBASE-7503-v3-trunk.patch, 
 HBASE-7503-v4-trunk.patch, HBASE-7503-v5-trunk.patch, 
 HBASE-7503-v7-trunk.patch, HBASE-7503-v8-trunk.patch, 
 HBASE-7503-v9-trunk.patch

   Original Estimate: 5m
  Remaining Estimate: 5m

 We need to have a Boolean[] exists(ListGet gets) throws IOException method 
 implemented in HTableInterface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-7503) Add exists(List) in HTableInterface to allow multiple parallel exists at one time

2013-01-24 Thread Jean-Marc Spaggiari (JIRA)


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

Jean-Marc Spaggiari updated HBASE-7503:
---

Attachment: HBASE-7503-v13-trunk.patch

 Add exists(List) in HTableInterface to allow multiple parallel exists at one 
 time
 -

 Key: HBASE-7503
 URL: https://issues.apache.org/jira/browse/HBASE-7503
 Project: HBase
  Issue Type: Improvement
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-7503-v0-trunk.patch, HBASE-7503-v10-trunk.patch, 
 HBASE-7503-v11-trunk.patch, HBASE-7503-v12-trunk.patch, 
 HBASE-7503-v13-trunk.patch, HBASE-7503-v1-trunk.patch, 
 HBASE-7503-v2-trunk.patch, HBASE-7503-v2-trunk.patch, 
 HBASE-7503-v3-trunk.patch, HBASE-7503-v4-trunk.patch, 
 HBASE-7503-v5-trunk.patch, HBASE-7503-v7-trunk.patch, 
 HBASE-7503-v8-trunk.patch, HBASE-7503-v9-trunk.patch

   Original Estimate: 5m
  Remaining Estimate: 5m

 We need to have a Boolean[] exists(ListGet gets) throws IOException method 
 implemented in HTableInterface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-7503) Add exists(List) in HTableInterface to allow multiple parallel exists at one time

2013-01-24 Thread Jean-Marc Spaggiari (JIRA)


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

Jean-Marc Spaggiari updated HBASE-7503:
---

Status: Patch Available  (was: Open)

closestRowBefore added to RequestConverter parameters and ClientProtos.java 
back in the patch. I think I figure why I had some many troubles with adding 
ClientProtos.java and Protos.java. It's because eclipse don't add them on an 
patch if there was marked as Merge issue, until you un-marked them manually, 
even if you fix the issue... Anyway. This one now should be good...

 Add exists(List) in HTableInterface to allow multiple parallel exists at one 
 time
 -

 Key: HBASE-7503
 URL: https://issues.apache.org/jira/browse/HBASE-7503
 Project: HBase
  Issue Type: Improvement
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-7503-v0-trunk.patch, HBASE-7503-v10-trunk.patch, 
 HBASE-7503-v11-trunk.patch, HBASE-7503-v12-trunk.patch, 
 HBASE-7503-v13-trunk.patch, HBASE-7503-v1-trunk.patch, 
 HBASE-7503-v2-trunk.patch, HBASE-7503-v2-trunk.patch, 
 HBASE-7503-v3-trunk.patch, HBASE-7503-v4-trunk.patch, 
 HBASE-7503-v5-trunk.patch, HBASE-7503-v7-trunk.patch, 
 HBASE-7503-v8-trunk.patch, HBASE-7503-v9-trunk.patch

   Original Estimate: 5m
  Remaining Estimate: 5m

 We need to have a Boolean[] exists(ListGet gets) throws IOException method 
 implemented in HTableInterface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-7503) Add exists(List) in HTableInterface to allow multiple parallel exists at one time

2013-01-24 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-7503:
--

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

http://issues.apache.org/jira/secure/attachment/12566309/HBASE-7503-v13-trunk.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: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 introduce 2 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 lines longer than
100

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

org.apache.hadoop.hbase.security.access.TestZKPermissionsWatcher

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

This message is automatically generated.

Add exists(List) in HTableInterface to allow multiple parallel exists at one
time
-

Key: HBASE-7503
URL: https://issues.apache.org/jira/browse/HBASE-7503
Project: HBase
Issue Type: Improvement
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
Fix For: 0.96.0

Attachments: HBASE-7503-v0-trunk.patch, HBASE-7503-v10-trunk.patch,
HBASE-7503-v11-trunk.patch, HBASE-7503-v12-trunk.patch,
HBASE-7503-v13-trunk.patch, HBASE-7503-v1-trunk.patch,
HBASE-7503-v2-trunk.patch, HBASE-7503-v2-trunk.patch,
HBASE-7503-v3-trunk.patch, HBASE-7503-v4-trunk.patch,
HBASE-7503-v5-trunk.patch, HBASE-7503-v7-trunk.patch,
HBASE-7503-v8-trunk.patch, HBASE-7503-v9-trunk.patch

Original Estimate: 5m
Remaining Estimate: 5m

We need to have a Boolean[] exists(ListGet gets) throws IOException method
implemented in HTableInterface.

[jira] [Commented] (HBASE-7638) [0.94] region cache entry should only be removed on error if the error is from the server currently in cache

2013-01-24 Thread Ted Yu (JIRA)


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

Ted Yu commented on HBASE-7638:
---

0.94 builds #762 and #763 hung where the patch was reverted.

I think there should be some other change(s) that caused the hang.

 [0.94] region cache entry should only be removed on error if the error is 
 from the server currently in cache
 

 Key: HBASE-7638
 URL: https://issues.apache.org/jira/browse/HBASE-7638
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.4
Reporter: Sergey Shelukhin
Assignee: Sergey Shelukhin
Priority: Minor
 Fix For: 0.94.5

 Attachments: HBASE-7638-v0.patch


 See HBASE-7268. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-7503) Add exists(List) in HTableInterface to allow multiple parallel exists at one time

2013-01-24 Thread Jean-Marc Spaggiari (JIRA)


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

Jean-Marc Spaggiari commented on HBASE-7503:


I ran org.apache.hadoop.hbase.client.TestFromClientSide3 and it's working fine 
locally.

Hadoop QA failed on 
org.apache.hadoop.hbase.security.access.TestZKPermissionsWatcher.testPermissionsWatcher
 which seems not related to this patch.

{code}
---
 T E S T S
---
Running org.apache.hadoop.hbase.client.TestFromClientSide3
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 131.651 sec

Results :

Tests run: 5, Failures: 0, Errors: 0, Skipped: 0
{code}

{code}
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] HBase . SUCCESS [4.311s]
[INFO] HBase - Common  SUCCESS [4.439s]
[INFO] HBase - Protocol .. SUCCESS [9.436s]
[INFO] HBase - Client  SUCCESS [0.309s]
[INFO] HBase - Hadoop Compatibility .. SUCCESS [0.222s]
[INFO] HBase - Hadoop One Compatibility .. SUCCESS [0.678s]
[INFO] HBase - Server  SUCCESS [2:26.146s]
[INFO] HBase - Integration Tests . SUCCESS [4.427s]
[INFO] HBase - Examples .. SUCCESS [2.638s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
{code}

 Add exists(List) in HTableInterface to allow multiple parallel exists at one 
 time
 -

 Key: HBASE-7503
 URL: https://issues.apache.org/jira/browse/HBASE-7503
 Project: HBase
  Issue Type: Improvement
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-7503-v0-trunk.patch, HBASE-7503-v10-trunk.patch, 
 HBASE-7503-v11-trunk.patch, HBASE-7503-v12-trunk.patch, 
 HBASE-7503-v13-trunk.patch, HBASE-7503-v1-trunk.patch, 
 HBASE-7503-v2-trunk.patch, HBASE-7503-v2-trunk.patch, 
 HBASE-7503-v3-trunk.patch, HBASE-7503-v4-trunk.patch, 
 HBASE-7503-v5-trunk.patch, HBASE-7503-v7-trunk.patch, 
 HBASE-7503-v8-trunk.patch, HBASE-7503-v9-trunk.patch

   Original Estimate: 5m
  Remaining Estimate: 5m

 We need to have a Boolean[] exists(ListGet gets) throws IOException method 
 implemented in HTableInterface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-7503) Add exists(List) in HTableInterface to allow multiple parallel exists at one time

2013-01-24 Thread Ted Yu (JIRA)


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

Ted Yu commented on HBASE-7503:
---

@Jean-Marc:
Mind attaching your patch again ?

 Add exists(List) in HTableInterface to allow multiple parallel exists at one 
 time
 -

 Key: HBASE-7503
 URL: https://issues.apache.org/jira/browse/HBASE-7503
 Project: HBase
  Issue Type: Improvement
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-7503-v0-trunk.patch, HBASE-7503-v10-trunk.patch, 
 HBASE-7503-v11-trunk.patch, HBASE-7503-v12-trunk.patch, 
 HBASE-7503-v13-trunk.patch, HBASE-7503-v1-trunk.patch, 
 HBASE-7503-v2-trunk.patch, HBASE-7503-v2-trunk.patch, 
 HBASE-7503-v3-trunk.patch, HBASE-7503-v4-trunk.patch, 
 HBASE-7503-v5-trunk.patch, HBASE-7503-v7-trunk.patch, 
 HBASE-7503-v8-trunk.patch, HBASE-7503-v9-trunk.patch

   Original Estimate: 5m
  Remaining Estimate: 5m

 We need to have a Boolean[] exists(ListGet gets) throws IOException method 
 implemented in HTableInterface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-7503) Add exists(List) in HTableInterface to allow multiple parallel exists at one time

2013-01-24 Thread Jean-Marc Spaggiari (JIRA)


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

Jean-Marc Spaggiari commented on HBASE-7503:


The same version? Or should I increment the version to get it processed?

 Add exists(List) in HTableInterface to allow multiple parallel exists at one 
 time
 -

 Key: HBASE-7503
 URL: https://issues.apache.org/jira/browse/HBASE-7503
 Project: HBase
  Issue Type: Improvement
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-7503-v0-trunk.patch, HBASE-7503-v10-trunk.patch, 
 HBASE-7503-v11-trunk.patch, HBASE-7503-v12-trunk.patch, 
 HBASE-7503-v13-trunk.patch, HBASE-7503-v1-trunk.patch, 
 HBASE-7503-v2-trunk.patch, HBASE-7503-v2-trunk.patch, 
 HBASE-7503-v3-trunk.patch, HBASE-7503-v4-trunk.patch, 
 HBASE-7503-v5-trunk.patch, HBASE-7503-v7-trunk.patch, 
 HBASE-7503-v8-trunk.patch, HBASE-7503-v9-trunk.patch

   Original Estimate: 5m
  Remaining Estimate: 5m

 We need to have a Boolean[] exists(ListGet gets) throws IOException method 
 implemented in HTableInterface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-7503) Add exists(List) in HTableInterface to allow multiple parallel exists at one time

2013-01-24 Thread Ted Yu (JIRA)


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

Ted Yu commented on HBASE-7503:
---

Hadoop QA looks at attachment Id, not file name. Meaning, attaching same file 
would do.

 Add exists(List) in HTableInterface to allow multiple parallel exists at one 
 time
 -

 Key: HBASE-7503
 URL: https://issues.apache.org/jira/browse/HBASE-7503
 Project: HBase
  Issue Type: Improvement
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-7503-v0-trunk.patch, HBASE-7503-v10-trunk.patch, 
 HBASE-7503-v11-trunk.patch, HBASE-7503-v12-trunk.patch, 
 HBASE-7503-v13-trunk.patch, HBASE-7503-v1-trunk.patch, 
 HBASE-7503-v2-trunk.patch, HBASE-7503-v2-trunk.patch, 
 HBASE-7503-v3-trunk.patch, HBASE-7503-v4-trunk.patch, 
 HBASE-7503-v5-trunk.patch, HBASE-7503-v7-trunk.patch, 
 HBASE-7503-v8-trunk.patch, HBASE-7503-v9-trunk.patch

   Original Estimate: 5m
  Remaining Estimate: 5m

 We need to have a Boolean[] exists(ListGet gets) throws IOException method 
 implemented in HTableInterface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

1 2 3 >

1 - 100 of 276 matches

Mail list logo