[jira] [Updated] (HBASE-3909) Add dynamic config
[ https://issues.apache.org/jira/browse/HBASE-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] binlijin updated HBASE-3909: Attachment: HBASE-3909-backport-from-fb-for-trunk-3.patch > Add dynamic config > -- > > Key: HBASE-3909 > URL: https://issues.apache.org/jira/browse/HBASE-3909 > Project: HBase > Issue Type: New Feature >Reporter: stack >Assignee: Subbu M Iyer > Attachments: 3909-102812.patch, 3909-102912.patch, 3909-v1.patch, > 3909.v1, 3909_090712-2.patch, HBASE-3909-backport-from-fb-for-trunk-2.patch, > HBASE-3909-backport-from-fb-for-trunk-3.patch, > HBASE-3909-backport-from-fb-for-trunk.patch, HBase Cluster Config > Details.xlsx, patch-v2.patch, testMasterNoCluster.stack > > > I'm sure this issue exists already, at least as part of the discussion around > making online schema edits possible, but no hard this having its own issue. > Ted started a conversation on this topic up on dev and Todd suggested we > lookd at how Hadoop did it over in HADOOP-7001 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-5356) region_mover.rb can hang if table region it belongs to is deleted.
[
https://issues.apache.org/jira/browse/HBASE-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894235#comment-13894235
]
stack commented on HBASE-5356:
--
lgtm Jimmy. How'd you test it?
> region_mover.rb can hang if table region it belongs to is deleted.
> --
>
> Key: HBASE-5356
> URL: https://issues.apache.org/jira/browse/HBASE-5356
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.90.3, 0.92.0, 0.94.0
>Reporter: Jonathan Hsieh
>Assignee: Jimmy Xiang
>Priority: Minor
> Attachments: hbase-5356.patch
>
>
> I was testing the region_mover.rb script on a loaded hbase and noticed that
> it can hang (thus hanging graceful shutdown) if a region that it is
> attempting to move gets deleted (by a table delete operation).
> Here's the start of the relevent stack dump
> {code}
> 12/02/08 13:27:13 WARN client.HConnectionManager$HConnectionImplementation:
> Encountered problems when prefetch META table:
> org.apache.hadoop.hbase.TableNotFoundException: Cannot find row in .META. for
> table: TestLoadAndVerify_1328735001040, row=TestLoadAnd\
> Verify_1328735001040,yC^P\xD7\x945\xD4,99
> at
> org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:136)
> at
> org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:95)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.prefetchRegionCache(HConnectionManager.java:64\
> 9)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegionInMeta(HConnectionManager.java:703\
> )
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:594)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.relocateRegion(HConnectionManager.java:565)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionLocation(HConnectionManager.java:416)
> at
> org.apache.hadoop.hbase.client.ServerCallable.instantiateServer(ServerCallable.java:57)
> at
> org.apache.hadoop.hbase.client.ScannerCallable.instantiateServer(ScannerCallable.java:63)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.\
> java:1018)
> at
> org.apache.hadoop.hbase.client.HTable$ClientScanner.nextScanner(HTable.java:1104)
> at
> org.apache.hadoop.hbase.client.HTable$ClientScanner.initialize(HTable.java:1027)
> at org.apache.hadoop.hbase.client.HTable.getScanner(HTable.java:535)
> at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.jruby.javasupport.JavaMethod.invokeDirectWithExceptionHandling(JavaMethod.java:525)
> at org.jruby.javasupport.JavaMethod.invokeDirect(JavaMethod.java:380)
> at
> org.jruby.java.invokers.InstanceMethodInvoker.call(InstanceMethodInvoker.java:58)
> at
> org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:137)
> at
> usr.lib.hbase.bin.region_mover.method__7$RUBY$isSuccessfulScan(/usr/lib/hbase/bin/region_mover.rb:133)
> at
> usr$lib$hbase$bin$region_mover#method__7$RUBY$isSuccessfulScan.call(usr$lib$hbase$bin$region_mover#method__7$RUBY$isSucces\
> sfulScan:65535)
> at
> usr$lib$hbase$bin$region_mover#method__7$RUBY$isSuccessfulScan.call(usr$lib$hbase$bin$region_mover#method__7$RUBY$isSucces\
> sfulScan:65535)
> at
> org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:171)
> at
> usr.lib.hbase.bin.region_mover.block_4$RUBY$__for__(/usr/lib/hbase/bin/region_mover.rb:326)
> at
> usr$lib$hbase$bin$region_mover#block_4$RUBY$__for__.call(usr$lib$hbase$bin$region_mover#block_4$RUBY$__for__:65535)
> at org.jruby.runtime.CompiledBlock.yield(CompiledBlock.java:133)
> at org.jruby.runtime.BlockBody.call(BlockBody.java:73)
> at org.jruby.runtime.Block.call(Block.java:89)
> at org.jruby.RubyProc.call(RubyProc.java:268)
> at org.jruby.RubyProc.call(RubyProc.java:228)
> at org.jruby.RubyProc$i$0$0$call.call(RubyProc$i$0$0$call.gen:65535)
> at
> org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:209)
> at
> org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:205)
> at
> org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:137)
> at org.jruby.ast.CallOneArgNode.interpret(CallOneArgNode.java:57)
>
[jira] [Updated] (HBASE-10313) Duplicate servlet-api jars in hbase 0.96.0
[
https://issues.apache.org/jira/browse/HBASE-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-10313:
--
Attachment: 10313v2.txt
Trunk version
> Duplicate servlet-api jars in hbase 0.96.0
> --
>
> Key: HBASE-10313
> URL: https://issues.apache.org/jira/browse/HBASE-10313
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 0.96.2, 0.98.1, 0.99.0
>
> Attachments: 10313.txt, 10313v2.txt
>
>
> On mailing list, http://search-hadoop.com/m/wtCkHs5Ujq, [~jerryhe] reports we
> have doubled jars:
> {code}
> [biadmin@hdtest009 lib]$ ls -l jsp-api*
> -rw-rw-r-- 1 biadmin biadmin 134910 Sep 17 01:13 jsp-api-2.1-6.1.14.jar
> -rw-rw-r-- 1 biadmin biadmin 100636 Sep 17 01:27 jsp-api-2.1.jar
> [biadmin@hdtest009 lib]$ ls -l servlet-api*
> -rw-rw-r-- 1 biadmin biadmin 132368 Sep 17 01:13 servlet-api-2.5-6.1.14.jar
> -rw-rw-r-- 1 biadmin biadmin 105112 Sep 17 01:12 servlet-api-2.5.jar
> {code}
> Fix in 0.96.2.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10340) [BACKPORT] HBASE-9892 Add info port to ServerName to support multi instances in a node
[ https://issues.apache.org/jira/browse/HBASE-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894231#comment-13894231 ] stack commented on HBASE-10340: --- I applied to 0.96 (thanks for reminder on the including hbase-10334 [~enis]). Let me test it tomorrow [~lhofhansl] to make sure can have a cluster that has a mix to make sure it ok before 0.94. > [BACKPORT] HBASE-9892 Add info port to ServerName to support multi instances > in a node > -- > > Key: HBASE-10340 > URL: https://issues.apache.org/jira/browse/HBASE-10340 > Project: HBase > Issue Type: Bug >Reporter: stack > Fix For: 0.96.2, 0.94.17 > > > Backport this patch after testing it does not break anything. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-3909) Add dynamic config
[
https://issues.apache.org/jira/browse/HBASE-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894230#comment-13894230
]
binlijin commented on HBASE-3909:
-
bq. Pardon me. I don't follow. We can't lose the setting of short circuit reads
on reload of configs. Do you think this will happen?
Some configs are hard or not impossible to take effect dynamically right now
for example： zookeeper.session.timeout, hbase.regionserver.metahandler.count
and so on.
If we want short circuit reads to take effect dynamically we must change HDFS
Client.
{code}
DFSClient
/**
* DFSClient configuration
*/
public static class Conf {
final boolean useLegacyBlockReader;
final boolean useLegacyBlockReaderLocal;
final String domainSocketPath;
final boolean skipShortCircuitChecksums;
final int shortCircuitBufferSize;
final boolean shortCircuitLocalReads;
final boolean domainSocketDataTraffic;
final int shortCircuitStreamsCacheSize;
final long shortCircuitStreamsCacheExpiryMs;
}
{code}
[~stack]
> Add dynamic config
> --
>
> Key: HBASE-3909
> URL: https://issues.apache.org/jira/browse/HBASE-3909
> Project: HBase
> Issue Type: New Feature
>Reporter: stack
>Assignee: Subbu M Iyer
> Attachments: 3909-102812.patch, 3909-102912.patch, 3909-v1.patch,
> 3909.v1, 3909_090712-2.patch, HBASE-3909-backport-from-fb-for-trunk-2.patch,
> HBASE-3909-backport-from-fb-for-trunk.patch, HBase Cluster Config
> Details.xlsx, patch-v2.patch, testMasterNoCluster.stack
>
>
> I'm sure this issue exists already, at least as part of the discussion around
> making online schema edits possible, but no hard this having its own issue.
> Ted started a conversation on this topic up on dev and Todd suggested we
> lookd at how Hadoop did it over in HADOOP-7001
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10334) RegionServer links in table.jsp is broken
[ https://issues.apache.org/jira/browse/HBASE-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-10334: -- Fix Version/s: 0.96.2 > RegionServer links in table.jsp is broken > - > > Key: HBASE-10334 > URL: https://issues.apache.org/jira/browse/HBASE-10334 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.98.0, 0.96.2, 0.99.0 > > Attachments: hbase-10334_v1.patch > > > The links to RS's seems to be broken in table.jsp after HBASE-9892. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10313) Duplicate servlet-api jars in hbase 0.96.0
[
https://issues.apache.org/jira/browse/HBASE-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894229#comment-13894229
]
Hadoop QA commented on HBASE-10313:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12627557/10313.txt
against trunk revision .
ATTACHMENT ID: 12627557
{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:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8623//console
This message is automatically generated.
> Duplicate servlet-api jars in hbase 0.96.0
> --
>
> Key: HBASE-10313
> URL: https://issues.apache.org/jira/browse/HBASE-10313
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 0.96.2, 0.98.1, 0.99.0
>
> Attachments: 10313.txt
>
>
> On mailing list, http://search-hadoop.com/m/wtCkHs5Ujq, [~jerryhe] reports we
> have doubled jars:
> {code}
> [biadmin@hdtest009 lib]$ ls -l jsp-api*
> -rw-rw-r-- 1 biadmin biadmin 134910 Sep 17 01:13 jsp-api-2.1-6.1.14.jar
> -rw-rw-r-- 1 biadmin biadmin 100636 Sep 17 01:27 jsp-api-2.1.jar
> [biadmin@hdtest009 lib]$ ls -l servlet-api*
> -rw-rw-r-- 1 biadmin biadmin 132368 Sep 17 01:13 servlet-api-2.5-6.1.14.jar
> -rw-rw-r-- 1 biadmin biadmin 105112 Sep 17 01:12 servlet-api-2.5.jar
> {code}
> Fix in 0.96.2.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10482) ReplicationSyncUp doesn't clean up its ZK, needed for tests
[
https://issues.apache.org/jira/browse/HBASE-10482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894227#comment-13894227
]
stack commented on HBASE-10482:
---
+1 try it. Lets see if it helps.
> ReplicationSyncUp doesn't clean up its ZK, needed for tests
> ---
>
> Key: HBASE-10482
> URL: https://issues.apache.org/jira/browse/HBASE-10482
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.96.1, 0.94.16
>Reporter: Jean-Daniel Cryans
>Assignee: Jean-Daniel Cryans
> Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.17
>
> Attachments: HBASE-10249.patch
>
>
> TestReplicationSyncUpTool failed again:
> https://builds.apache.org/job/HBase-TRUNK/4895/testReport/junit/org.apache.hadoop.hbase.replication/TestReplicationSyncUpTool/testSyncUpTool/
> It's not super obvious why only one of the two tables is replicated, the test
> could use some more logging, but I understand it this way:
> The first ReplicationSyncUp gets started and for some reason it cannot
> replicate the data:
> {noformat}
> 2014-02-06 21:32:19,811 INFO [Thread-1372]
> regionserver.ReplicationSourceManager(203): Current list of replicators:
> [1391722339091.SyncUpTool.replication.org,1234,1,
> quirinus.apache.org,37045,1391722237951,
> quirinus.apache.org,33502,1391722238125] other RSs: []
> 2014-02-06 21:32:19,811 INFO [Thread-1372.replicationSource,1]
> regionserver.ReplicationSource(231): Replicating
> db42e7fc-7f29-4038-9292-d85ea8b9994b -> 783c0ab2-4ff9-4dc0-bb38-86bf31d1d817
> 2014-02-06 21:32:19,892 TRACE [Thread-1372.replicationSource,2]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 1
> 2014-02-06 21:32:19,911 TRACE [Thread-1372.replicationSource,1]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 1
> 2014-02-06 21:32:20,094 TRACE [Thread-1372.replicationSource,2]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 2
> ...
> 2014-02-06 21:32:23,414 TRACE [Thread-1372.replicationSource,1]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 8
> 2014-02-06 21:32:23,673 INFO [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(169): Moving
> quirinus.apache.org,37045,1391722237951's hlogs to my queue
> 2014-02-06 21:32:23,768 DEBUG [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(396): Creating
> quirinus.apache.org%2C37045%2C1391722237951.1391722243779 with data 10803
> 2014-02-06 21:32:23,842 DEBUG [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(396): Creating
> quirinus.apache.org%2C37045%2C1391722237951.1391722243779 with data 10803
> 2014-02-06 21:32:24,297 TRACE [Thread-1372.replicationSource,2]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 9
> 2014-02-06 21:32:24,314 TRACE [Thread-1372.replicationSource,1]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 9
> {noformat}
> Finally it gives up:
> {noformat}
> 2014-02-06 21:32:30,873 DEBUG [Thread-1372]
> replication.TestReplicationSyncUpTool(323): SyncUpAfterDelete failed at retry
> = 0, with rowCount_ht1TargetPeer1 =100 and rowCount_ht2TargetAtPeer1 =200
> {noformat}
> The syncUp tool has an ID you can follow, grep for
> syncupReplication1391722338885 or just the timestamp, and you can see it
> doing things after that. The reason is that the tool closes the
> ReplicationSourceManager but not the ZK connection, so events _still_ come in
> and NodeFailoverWorker _still_ tries to recover queues but then there's
> nothing to process them.
> Later in the logs you can see:
> {noformat}
> 2014-02-06 21:32:37,381 INFO [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(169): Moving
> quirinus.apache.org,33502,1391722238125's hlogs to my queue
> 2014-02-06 21:32:37,567 INFO [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(239): Won't transfer the queue, another
> RS took care of it because of: KeeperErrorCode = NoNode for
> /1/replication/rs/quirinus.apache.org,33502,1391722238125/lock
> {noformat}
> There shouldn't' be any racing, but now someone already moved
> "quirinus.apache.org,33502,1391722238125" away.
> FWIW I can't even make the test fail on my machine so I'm not 100% sure
> closing the ZK connection fixes the issue, but at least it's the right thing
> to do.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10313) Duplicate servlet-api jars in hbase 0.96.0
[
https://issues.apache.org/jira/browse/HBASE-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-10313:
--
Fix Version/s: 0.99.0
0.98.1
Assignee: stack
Status: Patch Available (was: Open)
> Duplicate servlet-api jars in hbase 0.96.0
> --
>
> Key: HBASE-10313
> URL: https://issues.apache.org/jira/browse/HBASE-10313
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 0.96.2, 0.98.1, 0.99.0
>
> Attachments: 10313.txt
>
>
> On mailing list, http://search-hadoop.com/m/wtCkHs5Ujq, [~jerryhe] reports we
> have doubled jars:
> {code}
> [biadmin@hdtest009 lib]$ ls -l jsp-api*
> -rw-rw-r-- 1 biadmin biadmin 134910 Sep 17 01:13 jsp-api-2.1-6.1.14.jar
> -rw-rw-r-- 1 biadmin biadmin 100636 Sep 17 01:27 jsp-api-2.1.jar
> [biadmin@hdtest009 lib]$ ls -l servlet-api*
> -rw-rw-r-- 1 biadmin biadmin 132368 Sep 17 01:13 servlet-api-2.5-6.1.14.jar
> -rw-rw-r-- 1 biadmin biadmin 105112 Sep 17 01:12 servlet-api-2.5.jar
> {code}
> Fix in 0.96.2.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10313) Duplicate servlet-api jars in hbase 0.96.0
[
https://issues.apache.org/jira/browse/HBASE-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-10313:
--
Attachment: 10313.txt
Fix the transitive include of the extra jsp-api and servlet-api and no longer
include stax-api (jdk6 has it now).
> Duplicate servlet-api jars in hbase 0.96.0
> --
>
> Key: HBASE-10313
> URL: https://issues.apache.org/jira/browse/HBASE-10313
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Priority: Critical
> Fix For: 0.96.2, 0.98.1, 0.99.0
>
> Attachments: 10313.txt
>
>
> On mailing list, http://search-hadoop.com/m/wtCkHs5Ujq, [~jerryhe] reports we
> have doubled jars:
> {code}
> [biadmin@hdtest009 lib]$ ls -l jsp-api*
> -rw-rw-r-- 1 biadmin biadmin 134910 Sep 17 01:13 jsp-api-2.1-6.1.14.jar
> -rw-rw-r-- 1 biadmin biadmin 100636 Sep 17 01:27 jsp-api-2.1.jar
> [biadmin@hdtest009 lib]$ ls -l servlet-api*
> -rw-rw-r-- 1 biadmin biadmin 132368 Sep 17 01:13 servlet-api-2.5-6.1.14.jar
> -rw-rw-r-- 1 biadmin biadmin 105112 Sep 17 01:12 servlet-api-2.5.jar
> {code}
> Fix in 0.96.2.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10080) Unnecessary call to locateRegion when creating an HTable instance
[ https://issues.apache.org/jira/browse/HBASE-10080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-10080: -- Fix Version/s: (was: 0.96.2) Moving out > Unnecessary call to locateRegion when creating an HTable instance > - > > Key: HBASE-10080 > URL: https://issues.apache.org/jira/browse/HBASE-10080 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.96.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon >Priority: Trivial > Fix For: 0.98.1 > > Attachments: 10080.v1.patch > > > It's more or less in contradiction with the objective of having lightweight > HTable objects and the data may be stale when we will use it -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10169) Batch coprocessor
[
https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894200#comment-13894200
]
Hadoop QA commented on HBASE-10169:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12627531/HBASE-10169-alternate-4.patch
against trunk revision .
ATTACHMENT ID: 12627531
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 17 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:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+private CoprocessorServiceResult(boolean noInit) { this.unknownFields
= com.google.protobuf.UnknownFieldSet.getDefaultInstance(); }
+private SumRequest(boolean noInit) { this.unknownFields =
com.google.protobuf.UnknownFieldSet.getDefaultInstance(); }
+ return
org.apache.hadoop.hbase.coprocessor.protobuf.generated.ColumnAggregationWithErrorsProtos.internal_static_SumRequest_descriptor;
+ return
org.apache.hadoop.hbase.coprocessor.protobuf.generated.ColumnAggregationWithErrorsProtos.internal_static_SumRequest_fieldAccessorTable
+
org.apache.hadoop.hbase.coprocessor.protobuf.generated.ColumnAggregationWithErrorsProtos.SumRequest.class,
org.apache.hadoop.hbase.coprocessor.protobuf.generated.ColumnAggregationWithErrorsProtos.SumRequest.Builder.class);
+ if (!(obj instanceof
org.apache.hadoop.hbase.coprocessor.protobuf.generated.ColumnAggregationWithErrorsProtos.SumRequest))
{
+
org.apache.hadoop.hbase.coprocessor.protobuf.generated.ColumnAggregationWithErrorsProtos.SumRequest
other =
(org.apache.hadoop.hbase.coprocessor.protobuf.generated.ColumnAggregationWithErrorsProtos.SumRequest)
obj;
+public static
org.apache.hadoop.hbase.coprocessor.protobuf.generated.ColumnAggregationWithErrorsProtos.SumRequest
parseFrom(
+public static
org.apache.hadoop.hbase.coprocessor.protobuf.generated.ColumnAggregationWithErrorsProtos.SumRequest
parseFrom(
+public static
org.apache.hadoop.hbase.coprocessor.protobuf.generated.ColumnAggregationWithErrorsProtos.SumRequest
parseFrom(byte[] data)
{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/8622//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8622//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8622//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8622//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8622//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8622//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8622//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8622//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8622//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8622//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8622//console
This message is automatically generated.
> Batch coprocessor
> -
>
> Key: HBASE-10169
> URL: https://issues.apache.org/jira/browse/HBASE-10169
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Affects Versions: 0.99.0
>Reporter: Jingcheng
[jira] [Updated] (HBASE-10169) Batch coprocessor
[ https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Helmling updated HBASE-10169: -- Attachment: HBASE-10169-alternate-4.patch Updated patch that fixes the remaining long line errors from HadoopQA in non-protobuf generated code. > Batch coprocessor > - > > Key: HBASE-10169 > URL: https://issues.apache.org/jira/browse/HBASE-10169 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 0.99.0 >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: Batch Coprocessor Design Document.docx, > HBASE-10169-V2.patch, HBASE-10169-V3.patch, HBASE-10169-V3.patch, > HBASE-10169-V4.patch, HBASE-10169-V5.patch, HBASE-10169-alternate-2.patch, > HBASE-10169-alternate-3.patch, HBASE-10169-alternate-4.patch, > HBASE-10169-alternate.patch, HBASE-10169.patch > > > This is designed to improve the coprocessor invocation in the client side. > Currently the coprocessor invocation is to send a call to each region. If > there’s one region server, and 100 regions are located in this server, each > coprocessor invocation will send 100 calls, each call uses a single thread in > the client side. The threads will run out soon when the coprocessor > invocations are heavy. > In this design, all the calls to the same region server will be grouped into > one in a single coprocessor invocation. This call will be spread into each > region in the server side. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (HBASE-10363) [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23 profiles.
[
https://issues.apache.org/jira/browse/HBASE-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl resolved HBASE-10363.
---
Resolution: Fixed
Assignee: Lars Hofhansl
Hadoop Flags: Reviewed
Committed to 0.94 only.
Thanks Jon.
> [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23
> profiles.
> ---
>
> Key: HBASE-10363
> URL: https://issues.apache.org/jira/browse/HBASE-10363
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.15
>Reporter: Jonathan Hsieh
>Assignee: Lars Hofhansl
>Priority: Critical
> Fix For: 0.94.17
>
> Attachments: 10363.txt
>
>
> From tip of 0.94 and from 0.94.15.
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=2.0
> -Dtest=TestInputSampler,TestInputSamplerTool -PlocalTests
> ...
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool
> Tests run: 4, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 3.718 sec <<<
> FAILURE!
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.666 sec <<<
> FAILURE!
> Results :
> Tests in error:
>
> testSplitInterval(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitRamdom(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSample(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
>
> testIntervalSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
> Tests run: 6, Failures: 0, Errors: 5, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[
https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894111#comment-13894111
]
Hadoop QA commented on HBASE-10479:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12627514/HBASE-10479.01.patch
against trunk revision .
ATTACHMENT ID: 12627514
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color: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/8619//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8619//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8619//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8619//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8619//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8619//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8619//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8619//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8619//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8619//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8619//console
This message is automatically generated.
> HConnection interface is public but is used internally, and contains a bunch
> of methods
> ---
>
> Key: HBASE-10479
> URL: https://issues.apache.org/jira/browse/HBASE-10479
> Project: HBase
> Issue Type: Improvement
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
> Attachments: HBASE-10479.01.patch, HBASE-10479.patch
>
>
> HConnection has too many methods for a public interface, and some of these
> should not be public.
> It is used extensively for internal purposes, so we keep adding methods to it
> that may not make sense for public interface.
> The idea is to create a separate internal interface inheriting HConnection,
> copy some methods to it and deprecate them on HConnection. New methods for
> internal use would be added to new interface; the deprecated methods would
> eventually be removed from public interface.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-5356) region_mover.rb can hang if table region it belongs to is deleted.
[
https://issues.apache.org/jira/browse/HBASE-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894179#comment-13894179
]
Hadoop QA commented on HBASE-5356:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12627521/hbase-5356.patch
against trunk revision .
ATTACHMENT ID: 12627521
{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:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color: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/8621//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8621//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8621//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8621//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8621//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8621//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8621//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8621//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8621//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8621//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8621//console
This message is automatically generated.
> region_mover.rb can hang if table region it belongs to is deleted.
> --
>
> Key: HBASE-5356
> URL: https://issues.apache.org/jira/browse/HBASE-5356
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.90.3, 0.92.0, 0.94.0
>Reporter: Jonathan Hsieh
>Assignee: Jimmy Xiang
>Priority: Minor
> Attachments: hbase-5356.patch
>
>
> I was testing the region_mover.rb script on a loaded hbase and noticed that
> it can hang (thus hanging graceful shutdown) if a region that it is
> attempting to move gets deleted (by a table delete operation).
> Here's the start of the relevent stack dump
> {code}
> 12/02/08 13:27:13 WARN client.HConnectionManager$HConnectionImplementation:
> Encountered problems when prefetch META table:
> org.apache.hadoop.hbase.TableNotFoundException: Cannot find row in .META. for
> table: TestLoadAndVerify_1328735001040, row=TestLoadAnd\
> Verify_1328735001040,yC^P\xD7\x945\xD4,99
> at
> org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:136)
> at
> org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:95)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.prefetchRegionCache(HConnectionManager.java:64\
> 9)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegionInMeta(HConnectionManager.java:703\
> )
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:594)
> at
> org.apache.h
[jira] [Commented] (HBASE-10363) [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23 profiles.
[
https://issues.apache.org/jira/browse/HBASE-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894171#comment-13894171
]
Hudson commented on HBASE-10363:
SUCCESS: Integrated in HBase-0.94-JDK7 #40 (See
[https://builds.apache.org/job/HBase-0.94-JDK7/40/])
HBASE-10363 [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop
2.0/23 profiles. (larsh: rev 1565511)
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/mapreduce/hadoopbackport/InputSampler.java
> [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23
> profiles.
> ---
>
> Key: HBASE-10363
> URL: https://issues.apache.org/jira/browse/HBASE-10363
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.15
>Reporter: Jonathan Hsieh
>Assignee: Lars Hofhansl
>Priority: Critical
> Fix For: 0.94.17
>
> Attachments: 10363.txt
>
>
> From tip of 0.94 and from 0.94.15.
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=2.0
> -Dtest=TestInputSampler,TestInputSamplerTool -PlocalTests
> ...
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool
> Tests run: 4, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 3.718 sec <<<
> FAILURE!
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.666 sec <<<
> FAILURE!
> Results :
> Tests in error:
>
> testSplitInterval(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitRamdom(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSample(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
>
> testIntervalSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
> Tests run: 6, Failures: 0, Errors: 5, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10363) [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23 profiles.
[
https://issues.apache.org/jira/browse/HBASE-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894169#comment-13894169
]
Hudson commented on HBASE-10363:
FAILURE: Integrated in HBase-0.94 #1275 (See
[https://builds.apache.org/job/HBase-0.94/1275/])
HBASE-10363 [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop
2.0/23 profiles. (larsh: rev 1565511)
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/mapreduce/hadoopbackport/InputSampler.java
> [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23
> profiles.
> ---
>
> Key: HBASE-10363
> URL: https://issues.apache.org/jira/browse/HBASE-10363
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.15
>Reporter: Jonathan Hsieh
>Assignee: Lars Hofhansl
>Priority: Critical
> Fix For: 0.94.17
>
> Attachments: 10363.txt
>
>
> From tip of 0.94 and from 0.94.15.
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=2.0
> -Dtest=TestInputSampler,TestInputSamplerTool -PlocalTests
> ...
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool
> Tests run: 4, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 3.718 sec <<<
> FAILURE!
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.666 sec <<<
> FAILURE!
> Results :
> Tests in error:
>
> testSplitInterval(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitRamdom(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSample(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
>
> testIntervalSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
> Tests run: 6, Failures: 0, Errors: 5, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10481) API Compatibility JDiff script does not properly handle arguments in reverse order
[ https://issues.apache.org/jira/browse/HBASE-10481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-10481: --- Fix Version/s: (was: 0.98.0) 0.98.1 > API Compatibility JDiff script does not properly handle arguments in reverse > order > -- > > Key: HBASE-10481 > URL: https://issues.apache.org/jira/browse/HBASE-10481 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 0.98.0, 0.94.16, 0.99.0, 0.96.1.1 >Reporter: Aleksandr Shulman >Assignee: Aleksandr Shulman >Priority: Minor > Fix For: 0.94.16, 0.98.1, 0.99.0, 0.96.1.1 > > > [~jmhsieh] found an issue when doing a diff between a pre-0.96 branch and a > post-0.96 branch. > Typically, if the pre-0.96 branch is specified first, and the post-0.96 > branch second, the exisitng logic handles it. > When it is in the reverse order, that logic is not handled properly. > The fix should address this. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10303) Have snappy support properly documented would be helpful to hadoop and hbase users
[ https://issues.apache.org/jira/browse/HBASE-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894131#comment-13894131 ] Hudson commented on HBASE-10303: SUCCESS: Integrated in HBase-TRUNK #4896 (See [https://builds.apache.org/job/HBase-TRUNK/4896/]) HBASE-10303 Have snappy support properly documented would be helpful to hadoop and hbase users (stack: rev 1565489) * /hbase/trunk/src/main/docbkx/book.xml > Have snappy support properly documented would be helpful to hadoop and hbase > users > -- > > Key: HBASE-10303 > URL: https://issues.apache.org/jira/browse/HBASE-10303 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Rural Hunter > > The currentl document for configuring snappy > support(http://hbase.apache.org/book/snappy.compression.html) is not complete > and it's a bit obscure. IMO, there are several improvments can be made: > 1. Describe the relationship among hadoop,hbase,snappy. Is the snappy > actually needed by hadoop hdfs or hbase itself? That's to make clear if you > need to configure snappy support in hbase or hadoop. > 2. It didn't mention the default hadoop binary package is compiled without > snappy support and you need to compile it with snappy option manually. > Actually it didn't work with any native libs on 64 bits OS as the > libhadoop.so in the binary package is only for 32 bits OS(this of course is a > hadoop issue not hbase. but it's good to mention it.). > 3. In my experience, I actually need to install both snappy and > hadoop-snappy. So the doc lack of the steps to install hadoop-snappy. > 4. During my set up, I found difference where hadoop and hbase to pick up the > native lib files. hadoop picks those files in ./lib while hbase picks in > ./lib/[PLATFORM]. If it's correct, it can also be mentioned. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10363) [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23 profiles.
[
https://issues.apache.org/jira/browse/HBASE-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894145#comment-13894145
]
Hudson commented on HBASE-10363:
SUCCESS: Integrated in HBase-0.94-security #402 (See
[https://builds.apache.org/job/HBase-0.94-security/402/])
HBASE-10363 [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop
2.0/23 profiles. (larsh: rev 1565511)
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/mapreduce/hadoopbackport/InputSampler.java
> [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23
> profiles.
> ---
>
> Key: HBASE-10363
> URL: https://issues.apache.org/jira/browse/HBASE-10363
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.15
>Reporter: Jonathan Hsieh
>Assignee: Lars Hofhansl
>Priority: Critical
> Fix For: 0.94.17
>
> Attachments: 10363.txt
>
>
> From tip of 0.94 and from 0.94.15.
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=2.0
> -Dtest=TestInputSampler,TestInputSamplerTool -PlocalTests
> ...
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool
> Tests run: 4, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 3.718 sec <<<
> FAILURE!
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.666 sec <<<
> FAILURE!
> Results :
> Tests in error:
>
> testSplitInterval(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitRamdom(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSample(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
>
> testIntervalSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
> Tests run: 6, Failures: 0, Errors: 5, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (HBASE-10483) Provide API for retrieving info port when hbase.master.info.port is set to 0
Ted Yu created HBASE-10483: -- Summary: Provide API for retrieving info port when hbase.master.info.port is set to 0 Key: HBASE-10483 URL: https://issues.apache.org/jira/browse/HBASE-10483 Project: HBase Issue Type: Improvement Reporter: Ted Yu When hbase.master.info.port is set to 0, info port is dynamically determined. An API should be provided so that client can retrieve the actual info port. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (HBASE-9881) enabling HBASE_ROOT_LOGGER in hbase-env.sh would suppress the hbase console output
[
https://issues.apache.org/jira/browse/HBASE-9881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
takeshi.miao resolved HBASE-9881.
-
Resolution: Not A Problem
> enabling HBASE_ROOT_LOGGER in hbase-env.sh would suppress the hbase console
> output
> --
>
> Key: HBASE-9881
> URL: https://issues.apache.org/jira/browse/HBASE-9881
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: takeshi.miao
>Priority: Trivial
>
> Currently, there seems two call paths to determine the value of
> _hbase.root.logger_ in log4j.properties file.
> 1. hbase -> hbase-config.sh -> hbase-env.sh (set _HBASE_ROOT_LOGGER_ if any)
> -> hbase (set default value to HBASE_ROOT_LOGGER if no variable declared)
> 2. hbase-daemon.sh -> hbase-config.sh -> hbase-env.sh (set
> _HBASE_ROOT_LOGGER_ if any) -> hbase-daemon.sh (set default value to
> HBASE_ROOT_LOGGER if no variable declared)
> We found an issue at call path#1, while using 'bin/hbase' the original
> +console output will redirect to the log file+ if the _HBASE_ROOT_LOGGER_
> enabled in hbase-env.sh
> for example
> 1. we use 'bin/hbase zkcli' to connect to zookeeper, will see following log
> output to the console...
> {noformat}
> # bin/hbase zkcli
> Connecting to scottm-hbase-1.lab:2181
> 2013-11-04 08:33:39,855 INFO [main] zookeeper.ZooKeeper: Client
> environment:zookeeper.version=3.4.5-1392090, built on 09/30/2012 17:52 GMT
> 2013-11-04 08:33:39,855 INFO [main] zookeeper.ZooKeeper: Client
> environment:host.name=scottm-hbase-1.lab
> 2013-11-04 08:33:39,856 INFO [main] zookeeper.ZooKeeper: Client
> environment:java.version=1.6.0_26
> 2013-11-04 08:33:39,856 INFO [main] zookeeper.ZooKeeper: Client
> environment:java.vendor=Sun Microsystems Inc.
> 2013-11-04 08:33:39,856 INFO [main] zookeeper.ZooKeeper: Client
> environment:java.home=/usr/java/jdk1.6.0_26/jre
> 2013-11-04 08:33:39,856 INFO [main] zookeeper.ZooKeeper: Client
> environment:java.class.path=/opt/hbase/bin/../conf:/usr/java/jdk1.6.0_26/lib/tools.jar:/opt/hbase/bin/..:/opt/hbase/bin/../lib/activation-1.1.jar:/opt/hbase/bin/../lib/asm-3.1.jar:/opt/hbase/bin/../lib/commons-beanutils-1.7.0.jar:/opt/hbase/bin/../lib/commons-beanutils-core-1.8.0.jar:/opt/hbase/bin/../lib/commons-cli-1.2.jar:/opt/hbase/bin/../lib/commons-codec-1.7.jar:/opt/hbase/bin/../lib/commons-collections-3.2.1.jar:/opt/hbase/bin/../lib/commons-configuration-1.6.jar:/opt/hbase/bin/../lib/commons-digester-1.8.jar:/opt/hbase/bin/../lib/commons-el-1.0.jar:/opt/hbase/bin/../lib/commons-httpclient-3.1.jar:/opt/hbase/bin/../lib/commons-io-2.4.jar:/opt/hbase/bin/../lib/commons-lang-2.6.jar:/opt/hbase/bin/../lib/commons-logging-1.1.1.jar:/opt/hbase/bin/../lib/commons-math-2.2.jar:/opt/hbase/bin/../lib/commons-net-1.4.1.jar:/opt/hbase/bin/../lib/core-3.1.1.jar:/opt/hbase/bin/../lib/findbugs-annotations-1.3.9-1.jar:/opt/hbase/bin/../lib/guava-12.0.1.jar:/opt/hbase/bin/../lib/hadoop-core-1.2.1.jar:/opt/hbase/bin/../lib/hamcrest-core-1.3.jar:/opt/hbase/bin/../lib/hbase-client-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-common-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-common-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT-tests.jar:/opt/hbase/bin/../lib/hbase-examples-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-hadoop1-compat-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-hadoop-compat-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-it-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-it-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT-tests.jar:/opt/hbase/bin/../lib/hbase-prefix-tree-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-protocol-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-server-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-server-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT-tests.jar:/opt/hbase/bin/../lib/hbase-shell-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-testing-util-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-thrift-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/high-scale-lib-1.1.1.jar:/opt/hbase/bin/../lib/htrace-core-2.01.jar:/opt/hbase/bin/../lib/httpclient-4.1.3.jar:/opt/hbase/bin/../lib/httpcore-4.1.3.jar:/opt/hbase/bin/../lib/jackson-core-asl-1.8.8.jar:/opt/hbase/bin/../lib/jackson-jaxrs-1.8.8.jar:/opt/hbase/bin/../lib/jackson-mapper-asl-1.8.8.jar:/opt/hbase/bin/../lib/jackson-xc-1.8.8.jar:/opt/hbase/bin/../lib/jamon-runtime-2.3.1.jar:/opt/hbase/bin/../lib/jasper-compiler-5.5.23.jar:/opt/hbase/bin/../lib/jasper-runtime-5.5.23.jar:/opt/hbase/bin/../lib/jaxb-api-2.2.2.jar:/opt/hbase/bin/../lib/jaxb-impl-2.2.3-1.jar:/opt/hbase/bin/../lib/jersey-core-1.8.jar:/opt/hbase/bin/../lib/jersey-json-1.8.jar:/opt/hb
[jira] [Commented] (HBASE-10482) ReplicationSyncUp doesn't clean up its ZK, needed for tests
[
https://issues.apache.org/jira/browse/HBASE-10482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894153#comment-13894153
]
Hadoop QA commented on HBASE-10482:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12627520/HBASE-10249.patch
against trunk revision .
ATTACHMENT ID: 12627520
{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:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color: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/8620//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8620//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8620//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8620//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8620//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8620//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8620//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8620//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8620//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8620//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8620//console
This message is automatically generated.
> ReplicationSyncUp doesn't clean up its ZK, needed for tests
> ---
>
> Key: HBASE-10482
> URL: https://issues.apache.org/jira/browse/HBASE-10482
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.96.1, 0.94.16
>Reporter: Jean-Daniel Cryans
>Assignee: Jean-Daniel Cryans
> Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.17
>
> Attachments: HBASE-10249.patch
>
>
> TestReplicationSyncUpTool failed again:
> https://builds.apache.org/job/HBase-TRUNK/4895/testReport/junit/org.apache.hadoop.hbase.replication/TestReplicationSyncUpTool/testSyncUpTool/
> It's not super obvious why only one of the two tables is replicated, the test
> could use some more logging, but I understand it this way:
> The first ReplicationSyncUp gets started and for some reason it cannot
> replicate the data:
> {noformat}
> 2014-02-06 21:32:19,811 INFO [Thread-1372]
> regionserver.ReplicationSourceManager(203): Current list of replicators:
> [1391722339091.SyncUpTool.replication.org,1234,1,
> quirinus.apache.org,37045,1391722237951,
> quirinus.apache.org,33502,1391722238125] other RSs: []
> 2014-02-06 21:32:19,811 INFO [Thread-1372.replicationSource,1]
> regionserver.ReplicationSource(231): Replicating
> db42e7fc-7f29-4038-9292-d85ea8b9994b -> 783c0ab2-4ff9-4dc0-bb38-86bf31d1d817
> 2014-02-06 21:32:19,892 TRACE [Thread-1372.replicationSource,2]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 1
> 2014-02-06 21:32:19,911 TRACE [Thread-1372.replicationSource,1]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 1
> 2014-02-06 21:32:20,094 TRACE [Thread-1372.replicationSource,2]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 2
[jira] [Commented] (HBASE-10363) [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23 profiles.
[
https://issues.apache.org/jira/browse/HBASE-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894152#comment-13894152
]
Hudson commented on HBASE-10363:
FAILURE: Integrated in HBase-0.94-on-Hadoop-2 #11 (See
[https://builds.apache.org/job/HBase-0.94-on-Hadoop-2/11/])
HBASE-10363 [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop
2.0/23 profiles. (larsh: rev 1565511)
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/mapreduce/hadoopbackport/InputSampler.java
> [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23
> profiles.
> ---
>
> Key: HBASE-10363
> URL: https://issues.apache.org/jira/browse/HBASE-10363
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.15
>Reporter: Jonathan Hsieh
>Assignee: Lars Hofhansl
>Priority: Critical
> Fix For: 0.94.17
>
> Attachments: 10363.txt
>
>
> From tip of 0.94 and from 0.94.15.
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=2.0
> -Dtest=TestInputSampler,TestInputSamplerTool -PlocalTests
> ...
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool
> Tests run: 4, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 3.718 sec <<<
> FAILURE!
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.666 sec <<<
> FAILURE!
> Results :
> Tests in error:
>
> testSplitInterval(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitRamdom(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSample(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
>
> testIntervalSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
> Tests run: 6, Failures: 0, Errors: 5, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10169) Batch coprocessor
[
https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894074#comment-13894074
]
Hadoop QA commented on HBASE-10169:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12627504/HBASE-10169-alternate-3.patch
against trunk revision .
ATTACHMENT ID: 12627504
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 17 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:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ * {@link HTable#batchCoprocessorService(MethodDescriptor, Message,
byte[], byte[], Batch.Callback, Message)}
+private CoprocessorServiceResult(boolean noInit) { this.unknownFields =
com.google.protobuf.UnknownFieldSet.getDefaultInstance(); }
+ private Message execServiceOnRegion(HRegion region, final
ClientProtos.CoprocessorServiceCall serviceCall)
+ * Test coprocessor endpoint that always returns {@code null} for requests to
the last region in the table. This
+LOG.info("Returning sum " + sumResult + " for region " +
Bytes.toStringBinary(env.getRegion().getRegionName()));
+ * Test coprocessor endpoint that always throws a {@link
DoNotRetryIOException} for requests on the last region
+ * in the table. This allows tests to ensure correct error handling of
coprocessor endpoints throwing exceptions.
+ // throw an exception for requests to the last region in the table, in
order to test error handling
+private SumRequest(boolean noInit) { this.unknownFields =
com.google.protobuf.UnknownFieldSet.getDefaultInstance(); }
+ return
org.apache.hadoop.hbase.coprocessor.protobuf.generated.ColumnAggregationWithErrorsProtos.internal_static_SumRequest_descriptor;
{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/8618//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8618//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8618//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8618//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8618//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8618//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8618//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8618//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8618//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8618//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8618//console
This message is automatically generated.
> Batch coprocessor
> -
>
> Key: HBASE-10169
> URL: https://issues.apache.org/jira/browse/HBASE-10169
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Affects Versions: 0.99.0
>Reporter: Jingcheng Du
>Assignee: Jingcheng Du
> Attachments: Batch Coprocessor Design Document.docx,
> HBASE-10169-V2.patch, HBASE-10169-V3.patch, HBASE-10169-V3.patch,
> HBASE-10169-V4.patch, HBASE-10169-V5.patch, HBASE-10169-alternate-2.patch,
> HBASE-10169-alternate-3.patch, HBASE-10169-alternate.patch, HBASE-10169.patch
>
>
> This is designed to improv
[jira] [Commented] (HBASE-10478) Hbase book presentations page has broken link
[ https://issues.apache.org/jira/browse/HBASE-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894068#comment-13894068 ] Hudson commented on HBASE-10478: FAILURE: Integrated in HBase-TRUNK-on-Hadoop-1.1 #82 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-1.1/82/]) HBASE-10478 [docs] HBase book presentations page has broken link (Vivek Ganesan) (jmhsieh: rev 1565427) * /hbase/trunk/src/main/docbkx/book.xml > Hbase book presentations page has broken link > - > > Key: HBASE-10478 > URL: https://issues.apache.org/jira/browse/HBASE-10478 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Vivek Ganesan >Assignee: Vivek Ganesan >Priority: Minor > Fix For: 0.99.0 > > Attachments: HBASE-10478.patch > > > Hbase book page http://hbase.apache.org/book/other.info.pres.html has a link > "Advanced HBase Schema Design". This presentation seems to have been moved > to a new URL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10337) HTable.get() uninteruptible
[ https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894066#comment-13894066 ] Hudson commented on HBASE-10337: FAILURE: Integrated in HBase-TRUNK-on-Hadoop-1.1 #82 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-1.1/82/]) HBASE-10477 Regression from HBASE-10337 (nkeywal: rev 1565365) * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java > HTable.get() uninteruptible > --- > > Key: HBASE-10337 > URL: https://issues.apache.org/jira/browse/HBASE-10337 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1 >Reporter: Jonathan Leech >Assignee: Nicolas Liochon > Fix For: 0.98.0, 0.99.0 > > Attachments: 10337-addendum.patch, 10337.v1.patch, 10337.v2.patch > > > I've got a stuck thread on HTable.get() that can't be interrupted, looks like > its designed to be interruptible but can't be in interrupted in practice due > to while loop. > The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line > 981, it catches InterruptedException then goes right back to waiting due to > the while loop. > It looks like future versions of the client (.95+) are significantly > different and might not have this problem... Not sure about release schedules > etc. or if this version is still getting patched. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10477) Regression from HBASE-10337
[ https://issues.apache.org/jira/browse/HBASE-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894067#comment-13894067 ] Hudson commented on HBASE-10477: FAILURE: Integrated in HBase-TRUNK-on-Hadoop-1.1 #82 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-1.1/82/]) HBASE-10477 Regression from HBASE-10337 (nkeywal: rev 1565365) * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java > Regression from HBASE-10337 > --- > > Key: HBASE-10477 > URL: https://issues.apache.org/jira/browse/HBASE-10477 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.99.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon >Priority: Critical > Fix For: 0.98.0, 0.99.0 > > Attachments: 10477.v1.patch > > > a piece of code that should not have make it... > ping [~andrew.purt...@gmail.com] -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-5356) region_mover.rb can hang if table region it belongs to is deleted.
[
https://issues.apache.org/jira/browse/HBASE-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894064#comment-13894064
]
Jimmy Xiang commented on HBASE-5356:
Posted a patch that handled cases when a table is disabled/deleted in the
middle.
> region_mover.rb can hang if table region it belongs to is deleted.
> --
>
> Key: HBASE-5356
> URL: https://issues.apache.org/jira/browse/HBASE-5356
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.90.3, 0.92.0, 0.94.0
>Reporter: Jonathan Hsieh
>Assignee: Jimmy Xiang
>Priority: Minor
> Attachments: hbase-5356.patch
>
>
> I was testing the region_mover.rb script on a loaded hbase and noticed that
> it can hang (thus hanging graceful shutdown) if a region that it is
> attempting to move gets deleted (by a table delete operation).
> Here's the start of the relevent stack dump
> {code}
> 12/02/08 13:27:13 WARN client.HConnectionManager$HConnectionImplementation:
> Encountered problems when prefetch META table:
> org.apache.hadoop.hbase.TableNotFoundException: Cannot find row in .META. for
> table: TestLoadAndVerify_1328735001040, row=TestLoadAnd\
> Verify_1328735001040,yC^P\xD7\x945\xD4,99
> at
> org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:136)
> at
> org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:95)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.prefetchRegionCache(HConnectionManager.java:64\
> 9)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegionInMeta(HConnectionManager.java:703\
> )
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:594)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.relocateRegion(HConnectionManager.java:565)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionLocation(HConnectionManager.java:416)
> at
> org.apache.hadoop.hbase.client.ServerCallable.instantiateServer(ServerCallable.java:57)
> at
> org.apache.hadoop.hbase.client.ScannerCallable.instantiateServer(ScannerCallable.java:63)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.\
> java:1018)
> at
> org.apache.hadoop.hbase.client.HTable$ClientScanner.nextScanner(HTable.java:1104)
> at
> org.apache.hadoop.hbase.client.HTable$ClientScanner.initialize(HTable.java:1027)
> at org.apache.hadoop.hbase.client.HTable.getScanner(HTable.java:535)
> at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.jruby.javasupport.JavaMethod.invokeDirectWithExceptionHandling(JavaMethod.java:525)
> at org.jruby.javasupport.JavaMethod.invokeDirect(JavaMethod.java:380)
> at
> org.jruby.java.invokers.InstanceMethodInvoker.call(InstanceMethodInvoker.java:58)
> at
> org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:137)
> at
> usr.lib.hbase.bin.region_mover.method__7$RUBY$isSuccessfulScan(/usr/lib/hbase/bin/region_mover.rb:133)
> at
> usr$lib$hbase$bin$region_mover#method__7$RUBY$isSuccessfulScan.call(usr$lib$hbase$bin$region_mover#method__7$RUBY$isSucces\
> sfulScan:65535)
> at
> usr$lib$hbase$bin$region_mover#method__7$RUBY$isSuccessfulScan.call(usr$lib$hbase$bin$region_mover#method__7$RUBY$isSucces\
> sfulScan:65535)
> at
> org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:171)
> at
> usr.lib.hbase.bin.region_mover.block_4$RUBY$__for__(/usr/lib/hbase/bin/region_mover.rb:326)
> at
> usr$lib$hbase$bin$region_mover#block_4$RUBY$__for__.call(usr$lib$hbase$bin$region_mover#block_4$RUBY$__for__:65535)
> at org.jruby.runtime.CompiledBlock.yield(CompiledBlock.java:133)
> at org.jruby.runtime.BlockBody.call(BlockBody.java:73)
> at org.jruby.runtime.Block.call(Block.java:89)
> at org.jruby.RubyProc.call(RubyProc.java:268)
> at org.jruby.RubyProc.call(RubyProc.java:228)
> at org.jruby.RubyProc$i$0$0$call.call(RubyProc$i$0$0$call.gen:65535)
> at
> org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:209)
> at
> org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:205)
> at
> org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:137)
> at org.jruby
[jira] [Commented] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[
https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894062#comment-13894062
]
Enis Soztutar commented on HBASE-10479:
---
Can you also move:
{code}
boolean isTableAvailable(TableName tableName, byte[][] splitKeys) throws
AdminService.BlockingInterface getAdmin(final ServerName serverName) throws
IOException;
ClientService.BlockingInterface getClient(final ServerName serverName) throws
IOException;
HRegionLocation getRegionLocation(TableName tableName, byte [] row,
boolean reload)
void clearCaches(final ServerName sn);
boolean isDeadServer(ServerName serverName);
{code}
I am not sure about setRegionCachePrefetch() and friends. Do people disable
region cache prefetch? Why would a user want to do that? Also isDeadServer()
seems like it does not belong to public interfaces.
While we are at it, lets change the public fields (public static fields) in HC
and HCM as well.
Can we also move this to HConnectionInternal :
HCM.injectNonceGeneratorForTesting()
HCM.execute() is marked private with annotation. But we still have the same
problem in HCM that it contains both public intended methods
(createConnection()) and private methods. Can we reduce the visibility or make
a HCMInternal or smt like that? Same for HCM.findException() and
HCM.setServerSideHConnectionRetries()
Below, we are not using provider?
{code}
+ public static HConnection createConnection(Configuration conf) throws
IOException {
+UserProvider provider = UserProvider.instantiate(conf);
+return createConnectionInternal(conf);
{code}
> HConnection interface is public but is used internally, and contains a bunch
> of methods
> ---
>
> Key: HBASE-10479
> URL: https://issues.apache.org/jira/browse/HBASE-10479
> Project: HBase
> Issue Type: Improvement
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
> Attachments: HBASE-10479.01.patch, HBASE-10479.patch
>
>
> HConnection has too many methods for a public interface, and some of these
> should not be public.
> It is used extensively for internal purposes, so we keep adding methods to it
> that may not make sense for public interface.
> The idea is to create a separate internal interface inheriting HConnection,
> copy some methods to it and deprecate them on HConnection. New methods for
> internal use would be added to new interface; the deprecated methods would
> eventually be removed from public interface.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10482) ReplicationSyncUp doesn't clean up its ZK, needed for tests
[
https://issues.apache.org/jira/browse/HBASE-10482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Daniel Cryans updated HBASE-10482:
---
Attachment: HBASE-10249.patch
Patch for trunk attached. It just adds the closing of the ZK watcher and some
debug logging in the test to make it easier to follow.
[~nidmhbase] would you mind taking a look at the patch, the test logs, and see
if it makes sense?
> ReplicationSyncUp doesn't clean up its ZK, needed for tests
> ---
>
> Key: HBASE-10482
> URL: https://issues.apache.org/jira/browse/HBASE-10482
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.96.1, 0.94.16
>Reporter: Jean-Daniel Cryans
>Assignee: Jean-Daniel Cryans
> Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.17
>
> Attachments: HBASE-10249.patch
>
>
> TestReplicationSyncUpTool failed again:
> https://builds.apache.org/job/HBase-TRUNK/4895/testReport/junit/org.apache.hadoop.hbase.replication/TestReplicationSyncUpTool/testSyncUpTool/
> It's not super obvious why only one of the two tables is replicated, the test
> could use some more logging, but I understand it this way:
> The first ReplicationSyncUp gets started and for some reason it cannot
> replicate the data:
> {noformat}
> 2014-02-06 21:32:19,811 INFO [Thread-1372]
> regionserver.ReplicationSourceManager(203): Current list of replicators:
> [1391722339091.SyncUpTool.replication.org,1234,1,
> quirinus.apache.org,37045,1391722237951,
> quirinus.apache.org,33502,1391722238125] other RSs: []
> 2014-02-06 21:32:19,811 INFO [Thread-1372.replicationSource,1]
> regionserver.ReplicationSource(231): Replicating
> db42e7fc-7f29-4038-9292-d85ea8b9994b -> 783c0ab2-4ff9-4dc0-bb38-86bf31d1d817
> 2014-02-06 21:32:19,892 TRACE [Thread-1372.replicationSource,2]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 1
> 2014-02-06 21:32:19,911 TRACE [Thread-1372.replicationSource,1]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 1
> 2014-02-06 21:32:20,094 TRACE [Thread-1372.replicationSource,2]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 2
> ...
> 2014-02-06 21:32:23,414 TRACE [Thread-1372.replicationSource,1]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 8
> 2014-02-06 21:32:23,673 INFO [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(169): Moving
> quirinus.apache.org,37045,1391722237951's hlogs to my queue
> 2014-02-06 21:32:23,768 DEBUG [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(396): Creating
> quirinus.apache.org%2C37045%2C1391722237951.1391722243779 with data 10803
> 2014-02-06 21:32:23,842 DEBUG [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(396): Creating
> quirinus.apache.org%2C37045%2C1391722237951.1391722243779 with data 10803
> 2014-02-06 21:32:24,297 TRACE [Thread-1372.replicationSource,2]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 9
> 2014-02-06 21:32:24,314 TRACE [Thread-1372.replicationSource,1]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 9
> {noformat}
> Finally it gives up:
> {noformat}
> 2014-02-06 21:32:30,873 DEBUG [Thread-1372]
> replication.TestReplicationSyncUpTool(323): SyncUpAfterDelete failed at retry
> = 0, with rowCount_ht1TargetPeer1 =100 and rowCount_ht2TargetAtPeer1 =200
> {noformat}
> The syncUp tool has an ID you can follow, grep for
> syncupReplication1391722338885 or just the timestamp, and you can see it
> doing things after that. The reason is that the tool closes the
> ReplicationSourceManager but not the ZK connection, so events _still_ come in
> and NodeFailoverWorker _still_ tries to recover queues but then there's
> nothing to process them.
> Later in the logs you can see:
> {noformat}
> 2014-02-06 21:32:37,381 INFO [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(169): Moving
> quirinus.apache.org,33502,1391722238125's hlogs to my queue
> 2014-02-06 21:32:37,567 INFO [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(239): Won't transfer the queue, another
> RS took care of it because of: KeeperErrorCode = NoNode for
> /1/replication/rs/quirinus.apache.org,33502,1391722238125/lock
> {noformat}
> There shouldn't' be any racing, but now someone already moved
> "quirinus.apache.org,33502,1391722238125" away.
> FWIW I can't even make the test fail on my machine so I'm not 100% sure
> closing the ZK connection fixes the issue, but at least it's the right thing
> to do.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-5356) region_mover.rb can hang if table region it belongs to is deleted.
[
https://issues.apache.org/jira/browse/HBASE-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Xiang updated HBASE-5356:
---
Attachment: hbase-5356.patch
> region_mover.rb can hang if table region it belongs to is deleted.
> --
>
> Key: HBASE-5356
> URL: https://issues.apache.org/jira/browse/HBASE-5356
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.90.3, 0.92.0, 0.94.0
>Reporter: Jonathan Hsieh
>Assignee: Jimmy Xiang
>Priority: Minor
> Attachments: hbase-5356.patch
>
>
> I was testing the region_mover.rb script on a loaded hbase and noticed that
> it can hang (thus hanging graceful shutdown) if a region that it is
> attempting to move gets deleted (by a table delete operation).
> Here's the start of the relevent stack dump
> {code}
> 12/02/08 13:27:13 WARN client.HConnectionManager$HConnectionImplementation:
> Encountered problems when prefetch META table:
> org.apache.hadoop.hbase.TableNotFoundException: Cannot find row in .META. for
> table: TestLoadAndVerify_1328735001040, row=TestLoadAnd\
> Verify_1328735001040,yC^P\xD7\x945\xD4,99
> at
> org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:136)
> at
> org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:95)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.prefetchRegionCache(HConnectionManager.java:64\
> 9)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegionInMeta(HConnectionManager.java:703\
> )
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:594)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.relocateRegion(HConnectionManager.java:565)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionLocation(HConnectionManager.java:416)
> at
> org.apache.hadoop.hbase.client.ServerCallable.instantiateServer(ServerCallable.java:57)
> at
> org.apache.hadoop.hbase.client.ScannerCallable.instantiateServer(ScannerCallable.java:63)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.\
> java:1018)
> at
> org.apache.hadoop.hbase.client.HTable$ClientScanner.nextScanner(HTable.java:1104)
> at
> org.apache.hadoop.hbase.client.HTable$ClientScanner.initialize(HTable.java:1027)
> at org.apache.hadoop.hbase.client.HTable.getScanner(HTable.java:535)
> at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.jruby.javasupport.JavaMethod.invokeDirectWithExceptionHandling(JavaMethod.java:525)
> at org.jruby.javasupport.JavaMethod.invokeDirect(JavaMethod.java:380)
> at
> org.jruby.java.invokers.InstanceMethodInvoker.call(InstanceMethodInvoker.java:58)
> at
> org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:137)
> at
> usr.lib.hbase.bin.region_mover.method__7$RUBY$isSuccessfulScan(/usr/lib/hbase/bin/region_mover.rb:133)
> at
> usr$lib$hbase$bin$region_mover#method__7$RUBY$isSuccessfulScan.call(usr$lib$hbase$bin$region_mover#method__7$RUBY$isSucces\
> sfulScan:65535)
> at
> usr$lib$hbase$bin$region_mover#method__7$RUBY$isSuccessfulScan.call(usr$lib$hbase$bin$region_mover#method__7$RUBY$isSucces\
> sfulScan:65535)
> at
> org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:171)
> at
> usr.lib.hbase.bin.region_mover.block_4$RUBY$__for__(/usr/lib/hbase/bin/region_mover.rb:326)
> at
> usr$lib$hbase$bin$region_mover#block_4$RUBY$__for__.call(usr$lib$hbase$bin$region_mover#block_4$RUBY$__for__:65535)
> at org.jruby.runtime.CompiledBlock.yield(CompiledBlock.java:133)
> at org.jruby.runtime.BlockBody.call(BlockBody.java:73)
> at org.jruby.runtime.Block.call(Block.java:89)
> at org.jruby.RubyProc.call(RubyProc.java:268)
> at org.jruby.RubyProc.call(RubyProc.java:228)
> at org.jruby.RubyProc$i$0$0$call.call(RubyProc$i$0$0$call.gen:65535)
> at
> org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:209)
> at
> org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:205)
> at
> org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:137)
> at org.jruby.ast.CallOneArgNode.interpret(CallOneArgNode.java:57)
> at org.jruby.ast.NewlineNode.interpret(Newl
[jira] [Updated] (HBASE-5356) region_mover.rb can hang if table region it belongs to is deleted.
[
https://issues.apache.org/jira/browse/HBASE-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Xiang updated HBASE-5356:
---
Status: Patch Available (was: Open)
> region_mover.rb can hang if table region it belongs to is deleted.
> --
>
> Key: HBASE-5356
> URL: https://issues.apache.org/jira/browse/HBASE-5356
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.0, 0.92.0, 0.90.3
>Reporter: Jonathan Hsieh
>Assignee: Jimmy Xiang
>Priority: Minor
> Attachments: hbase-5356.patch
>
>
> I was testing the region_mover.rb script on a loaded hbase and noticed that
> it can hang (thus hanging graceful shutdown) if a region that it is
> attempting to move gets deleted (by a table delete operation).
> Here's the start of the relevent stack dump
> {code}
> 12/02/08 13:27:13 WARN client.HConnectionManager$HConnectionImplementation:
> Encountered problems when prefetch META table:
> org.apache.hadoop.hbase.TableNotFoundException: Cannot find row in .META. for
> table: TestLoadAndVerify_1328735001040, row=TestLoadAnd\
> Verify_1328735001040,yC^P\xD7\x945\xD4,99
> at
> org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:136)
> at
> org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:95)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.prefetchRegionCache(HConnectionManager.java:64\
> 9)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegionInMeta(HConnectionManager.java:703\
> )
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:594)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.relocateRegion(HConnectionManager.java:565)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionLocation(HConnectionManager.java:416)
> at
> org.apache.hadoop.hbase.client.ServerCallable.instantiateServer(ServerCallable.java:57)
> at
> org.apache.hadoop.hbase.client.ScannerCallable.instantiateServer(ScannerCallable.java:63)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.\
> java:1018)
> at
> org.apache.hadoop.hbase.client.HTable$ClientScanner.nextScanner(HTable.java:1104)
> at
> org.apache.hadoop.hbase.client.HTable$ClientScanner.initialize(HTable.java:1027)
> at org.apache.hadoop.hbase.client.HTable.getScanner(HTable.java:535)
> at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.jruby.javasupport.JavaMethod.invokeDirectWithExceptionHandling(JavaMethod.java:525)
> at org.jruby.javasupport.JavaMethod.invokeDirect(JavaMethod.java:380)
> at
> org.jruby.java.invokers.InstanceMethodInvoker.call(InstanceMethodInvoker.java:58)
> at
> org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:137)
> at
> usr.lib.hbase.bin.region_mover.method__7$RUBY$isSuccessfulScan(/usr/lib/hbase/bin/region_mover.rb:133)
> at
> usr$lib$hbase$bin$region_mover#method__7$RUBY$isSuccessfulScan.call(usr$lib$hbase$bin$region_mover#method__7$RUBY$isSucces\
> sfulScan:65535)
> at
> usr$lib$hbase$bin$region_mover#method__7$RUBY$isSuccessfulScan.call(usr$lib$hbase$bin$region_mover#method__7$RUBY$isSucces\
> sfulScan:65535)
> at
> org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:171)
> at
> usr.lib.hbase.bin.region_mover.block_4$RUBY$__for__(/usr/lib/hbase/bin/region_mover.rb:326)
> at
> usr$lib$hbase$bin$region_mover#block_4$RUBY$__for__.call(usr$lib$hbase$bin$region_mover#block_4$RUBY$__for__:65535)
> at org.jruby.runtime.CompiledBlock.yield(CompiledBlock.java:133)
> at org.jruby.runtime.BlockBody.call(BlockBody.java:73)
> at org.jruby.runtime.Block.call(Block.java:89)
> at org.jruby.RubyProc.call(RubyProc.java:268)
> at org.jruby.RubyProc.call(RubyProc.java:228)
> at org.jruby.RubyProc$i$0$0$call.call(RubyProc$i$0$0$call.gen:65535)
> at
> org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:209)
> at
> org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:205)
> at
> org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:137)
> at org.jruby.ast.CallOneArgNode.interpret(CallOneArgNode.java:57)
> at org.jruby.ast.NewlineNode.interp
[jira] [Updated] (HBASE-10482) ReplicationSyncUp doesn't clean up its ZK, needed for tests
[
https://issues.apache.org/jira/browse/HBASE-10482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Daniel Cryans updated HBASE-10482:
---
Status: Patch Available (was: Open)
> ReplicationSyncUp doesn't clean up its ZK, needed for tests
> ---
>
> Key: HBASE-10482
> URL: https://issues.apache.org/jira/browse/HBASE-10482
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.94.16, 0.96.1
>Reporter: Jean-Daniel Cryans
>Assignee: Jean-Daniel Cryans
> Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.17
>
> Attachments: HBASE-10249.patch
>
>
> TestReplicationSyncUpTool failed again:
> https://builds.apache.org/job/HBase-TRUNK/4895/testReport/junit/org.apache.hadoop.hbase.replication/TestReplicationSyncUpTool/testSyncUpTool/
> It's not super obvious why only one of the two tables is replicated, the test
> could use some more logging, but I understand it this way:
> The first ReplicationSyncUp gets started and for some reason it cannot
> replicate the data:
> {noformat}
> 2014-02-06 21:32:19,811 INFO [Thread-1372]
> regionserver.ReplicationSourceManager(203): Current list of replicators:
> [1391722339091.SyncUpTool.replication.org,1234,1,
> quirinus.apache.org,37045,1391722237951,
> quirinus.apache.org,33502,1391722238125] other RSs: []
> 2014-02-06 21:32:19,811 INFO [Thread-1372.replicationSource,1]
> regionserver.ReplicationSource(231): Replicating
> db42e7fc-7f29-4038-9292-d85ea8b9994b -> 783c0ab2-4ff9-4dc0-bb38-86bf31d1d817
> 2014-02-06 21:32:19,892 TRACE [Thread-1372.replicationSource,2]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 1
> 2014-02-06 21:32:19,911 TRACE [Thread-1372.replicationSource,1]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 1
> 2014-02-06 21:32:20,094 TRACE [Thread-1372.replicationSource,2]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 2
> ...
> 2014-02-06 21:32:23,414 TRACE [Thread-1372.replicationSource,1]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 8
> 2014-02-06 21:32:23,673 INFO [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(169): Moving
> quirinus.apache.org,37045,1391722237951's hlogs to my queue
> 2014-02-06 21:32:23,768 DEBUG [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(396): Creating
> quirinus.apache.org%2C37045%2C1391722237951.1391722243779 with data 10803
> 2014-02-06 21:32:23,842 DEBUG [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(396): Creating
> quirinus.apache.org%2C37045%2C1391722237951.1391722243779 with data 10803
> 2014-02-06 21:32:24,297 TRACE [Thread-1372.replicationSource,2]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 9
> 2014-02-06 21:32:24,314 TRACE [Thread-1372.replicationSource,1]
> regionserver.ReplicationSource(596): No log to process, sleeping 100 times 9
> {noformat}
> Finally it gives up:
> {noformat}
> 2014-02-06 21:32:30,873 DEBUG [Thread-1372]
> replication.TestReplicationSyncUpTool(323): SyncUpAfterDelete failed at retry
> = 0, with rowCount_ht1TargetPeer1 =100 and rowCount_ht2TargetAtPeer1 =200
> {noformat}
> The syncUp tool has an ID you can follow, grep for
> syncupReplication1391722338885 or just the timestamp, and you can see it
> doing things after that. The reason is that the tool closes the
> ReplicationSourceManager but not the ZK connection, so events _still_ come in
> and NodeFailoverWorker _still_ tries to recover queues but then there's
> nothing to process them.
> Later in the logs you can see:
> {noformat}
> 2014-02-06 21:32:37,381 INFO [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(169): Moving
> quirinus.apache.org,33502,1391722238125's hlogs to my queue
> 2014-02-06 21:32:37,567 INFO [ReplicationExecutor-0]
> replication.ReplicationQueuesZKImpl(239): Won't transfer the queue, another
> RS took care of it because of: KeeperErrorCode = NoNode for
> /1/replication/rs/quirinus.apache.org,33502,1391722238125/lock
> {noformat}
> There shouldn't' be any racing, but now someone already moved
> "quirinus.apache.org,33502,1391722238125" away.
> FWIW I can't even make the test fail on my machine so I'm not 100% sure
> closing the ZK connection fixes the issue, but at least it's the right thing
> to do.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (HBASE-10482) ReplicationSyncUp doesn't clean up its ZK, needed for tests
Jean-Daniel Cryans created HBASE-10482:
--
Summary: ReplicationSyncUp doesn't clean up its ZK, needed for
tests
Key: HBASE-10482
URL: https://issues.apache.org/jira/browse/HBASE-10482
Project: HBase
Issue Type: Bug
Components: Replication
Affects Versions: 0.94.16, 0.96.1
Reporter: Jean-Daniel Cryans
Assignee: Jean-Daniel Cryans
Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.17
TestReplicationSyncUpTool failed again:
https://builds.apache.org/job/HBase-TRUNK/4895/testReport/junit/org.apache.hadoop.hbase.replication/TestReplicationSyncUpTool/testSyncUpTool/
It's not super obvious why only one of the two tables is replicated, the test
could use some more logging, but I understand it this way:
The first ReplicationSyncUp gets started and for some reason it cannot
replicate the data:
{noformat}
2014-02-06 21:32:19,811 INFO [Thread-1372]
regionserver.ReplicationSourceManager(203): Current list of replicators:
[1391722339091.SyncUpTool.replication.org,1234,1,
quirinus.apache.org,37045,1391722237951,
quirinus.apache.org,33502,1391722238125] other RSs: []
2014-02-06 21:32:19,811 INFO [Thread-1372.replicationSource,1]
regionserver.ReplicationSource(231): Replicating
db42e7fc-7f29-4038-9292-d85ea8b9994b -> 783c0ab2-4ff9-4dc0-bb38-86bf31d1d817
2014-02-06 21:32:19,892 TRACE [Thread-1372.replicationSource,2]
regionserver.ReplicationSource(596): No log to process, sleeping 100 times 1
2014-02-06 21:32:19,911 TRACE [Thread-1372.replicationSource,1]
regionserver.ReplicationSource(596): No log to process, sleeping 100 times 1
2014-02-06 21:32:20,094 TRACE [Thread-1372.replicationSource,2]
regionserver.ReplicationSource(596): No log to process, sleeping 100 times 2
...
2014-02-06 21:32:23,414 TRACE [Thread-1372.replicationSource,1]
regionserver.ReplicationSource(596): No log to process, sleeping 100 times 8
2014-02-06 21:32:23,673 INFO [ReplicationExecutor-0]
replication.ReplicationQueuesZKImpl(169): Moving
quirinus.apache.org,37045,1391722237951's hlogs to my queue
2014-02-06 21:32:23,768 DEBUG [ReplicationExecutor-0]
replication.ReplicationQueuesZKImpl(396): Creating
quirinus.apache.org%2C37045%2C1391722237951.1391722243779 with data 10803
2014-02-06 21:32:23,842 DEBUG [ReplicationExecutor-0]
replication.ReplicationQueuesZKImpl(396): Creating
quirinus.apache.org%2C37045%2C1391722237951.1391722243779 with data 10803
2014-02-06 21:32:24,297 TRACE [Thread-1372.replicationSource,2]
regionserver.ReplicationSource(596): No log to process, sleeping 100 times 9
2014-02-06 21:32:24,314 TRACE [Thread-1372.replicationSource,1]
regionserver.ReplicationSource(596): No log to process, sleeping 100 times 9
{noformat}
Finally it gives up:
{noformat}
2014-02-06 21:32:30,873 DEBUG [Thread-1372]
replication.TestReplicationSyncUpTool(323): SyncUpAfterDelete failed at retry =
0, with rowCount_ht1TargetPeer1 =100 and rowCount_ht2TargetAtPeer1 =200
{noformat}
The syncUp tool has an ID you can follow, grep for
syncupReplication1391722338885 or just the timestamp, and you can see it doing
things after that. The reason is that the tool closes the
ReplicationSourceManager but not the ZK connection, so events _still_ come in
and NodeFailoverWorker _still_ tries to recover queues but then there's nothing
to process them.
Later in the logs you can see:
{noformat}
2014-02-06 21:32:37,381 INFO [ReplicationExecutor-0]
replication.ReplicationQueuesZKImpl(169): Moving
quirinus.apache.org,33502,1391722238125's hlogs to my queue
2014-02-06 21:32:37,567 INFO [ReplicationExecutor-0]
replication.ReplicationQueuesZKImpl(239): Won't transfer the queue, another RS
took care of it because of: KeeperErrorCode = NoNode for
/1/replication/rs/quirinus.apache.org,33502,1391722238125/lock
{noformat}
There shouldn't' be any racing, but now someone already moved
"quirinus.apache.org,33502,1391722238125" away.
FWIW I can't even make the test fail on my machine so I'm not 100% sure closing
the ZK connection fixes the issue, but at least it's the right thing to do.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[ https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894056#comment-13894056 ] stack commented on HBASE-10479: --- Call it Cluster instead of HConnectionInternal or ClusterConnection which better describes what it actually does. HCI is an ugly name. Otherwise looks good to me [~sershe] > HConnection interface is public but is used internally, and contains a bunch > of methods > --- > > Key: HBASE-10479 > URL: https://issues.apache.org/jira/browse/HBASE-10479 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-10479.01.patch, HBASE-10479.patch > > > HConnection has too many methods for a public interface, and some of these > should not be public. > It is used extensively for internal purposes, so we keep adding methods to it > that may not make sense for public interface. > The idea is to create a separate internal interface inheriting HConnection, > copy some methods to it and deprecate them on HConnection. New methods for > internal use would be added to new interface; the deprecated methods would > eventually be removed from public interface. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10481) API Compatibility JDiff script does not properly handle arguments in reverse order
Aleksandr Shulman created HBASE-10481: - Summary: API Compatibility JDiff script does not properly handle arguments in reverse order Key: HBASE-10481 URL: https://issues.apache.org/jira/browse/HBASE-10481 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.96.1.1, 0.94.16, 0.98.0, 0.99.0 Reporter: Aleksandr Shulman Assignee: Aleksandr Shulman Priority: Minor Fix For: 0.98.0, 0.99.0, 0.96.1.1, 0.94.16 [~jmhsieh] found an issue when doing a diff between a pre-0.96 branch and a post-0.96 branch. Typically, if the pre-0.96 branch is specified first, and the post-0.96 branch second, the exisitng logic handles it. When it is in the reverse order, that logic is not handled properly. The fix should address this. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10475) TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent lease removal
[
https://issues.apache.org/jira/browse/HBASE-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894045#comment-13894045
]
Hudson commented on HBASE-10475:
FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #127 (See
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/127/])
HBASE-10475 TestRegionServerCoprocessorExceptionWithAbort may timeout due to
concurrent lease removal (tedyu: rev 1565386)
*
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/SimpleRegionObserver.java
> TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent
> lease removal
> -
>
> Key: HBASE-10475
> URL: https://issues.apache.org/jira/browse/HBASE-10475
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Minor
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10475-v1.txt, 10475-v2.txt,
> org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort-output.txt
>
>
> I got the following test failure:
> {code}
> testExceptionFromCoprocessorDuringPut(org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort)
> Time elapsed: 0.049 sec <<< ERROR!
> java.lang.Exception: test timed out after 6 milliseconds
> at java.lang.Object.wait(Native Method)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForNextTaskDone(AsyncProcess.java:837)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForMaximumCurrentTasks(AsyncProcess.java:863)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitUntilDone(AsyncProcess.java:876)
> at
> org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:945)
> at
> org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1225)
> at org.apache.hadoop.hbase.client.HTable.put(HTable.java:887)
> at
> org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort.testExceptionFromCoprocessorDuringPut(TestRegionServerCoprocessorExceptionWithAbort.java:106)
> {code}
> This was due to unexpected LeaseException bringing down region server:
> {code}
> 2014-02-05 19:28:24,752 ERROR [RS_OPEN_REGION-kiyo:56349-1]
> coprocessor.CoprocessorHost(760): The coprocessor
> org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort$BuggyRegionObserver
> threw an unexpected exception
> org.apache.hadoop.hbase.regionserver.LeaseException: lease 'x' does not exist
> at
> org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:221)
> at
> org.apache.hadoop.hbase.regionserver.Leases.cancelLease(Leases.java:206)
> at
> org.apache.hadoop.hbase.coprocessor.SimpleRegionObserver.start(SimpleRegionObserver.java:140)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.startup(CoprocessorHost.java:651)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadInstance(CoprocessorHost.java:261)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10472) Manage the interruption in ZKUtil#getData
[ https://issues.apache.org/jira/browse/HBASE-10472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894036#comment-13894036 ] Enis Soztutar commented on HBASE-10472: --- I guess we need this for checking the meta location from zk right? Do we need that to be interruptible as well? I guess we might need it if we ever want to go meta replicas. We are not setting the interrupted flag for the thread in ReplicationPeersZKImpl, ZKLeaderManager. Not sure whether they are needed. Can we get away with some of the changes, if we keep the original ZKUtil.getData() and have ZKUtil.getDataInterruptible() ? Other than those it looks good. > Manage the interruption in ZKUtil#getData > - > > Key: HBASE-10472 > URL: https://issues.apache.org/jira/browse/HBASE-10472 > Project: HBase > Issue Type: Bug > Components: Client, master, regionserver >Affects Versions: 0.98.0, 0.99.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.98.1, 0.99.0 > > Attachments: 10472.v1.patch, 10472.v2.patch > > > Many, but not all, methods in ZKUtil partly hides the interruption: they > return null or something like that. Many times, this will result in a NPE, or > something undefined. > This jira is limited to the getData to keep things small enough (it's used in > hbase-client code). > The code is supposed to behave at least 'as well as before', or better > (hopefully). > It could be included in a later .98 release (98.1) and in .99 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[ https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-10479: - Attachment: HBASE-10479.01.patch forgot the new file > HConnection interface is public but is used internally, and contains a bunch > of methods > --- > > Key: HBASE-10479 > URL: https://issues.apache.org/jira/browse/HBASE-10479 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-10479.01.patch, HBASE-10479.patch > > > HConnection has too many methods for a public interface, and some of these > should not be public. > It is used extensively for internal purposes, so we keep adding methods to it > that may not make sense for public interface. > The idea is to create a separate internal interface inheriting HConnection, > copy some methods to it and deprecate them on HConnection. New methods for > internal use would be added to new interface; the deprecated methods would > eventually be removed from public interface. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10480) TestLogRollPeriod#testWithEdits may fail due to insufficient waiting
Ted Yu created HBASE-10480:
--
Summary: TestLogRollPeriod#testWithEdits may fail due to
insufficient waiting
Key: HBASE-10480
URL: https://issues.apache.org/jira/browse/HBASE-10480
Project: HBase
Issue Type: Test
Reporter: Ted Yu
Priority: Minor
The test waits for minRolls rolls by sleeping:
{code}
Thread.sleep((minRolls + 1) * LOG_ROLL_PERIOD);
{code}
However, the above wait period may not be sufficient.
See
https://builds.apache.org/job/HBase-TRUNK/4895/testReport/junit/org.apache.hadoop.hbase.regionserver.wal/TestLogRollPeriod/testWithEdits/
:
{code}
2014-02-06 23:02:25,710 DEBUG [RS:0;quirinus:56476.logRoller]
regionserver.LogRoller(87): Hlog roll period 4000ms elapsed
...
2014-02-06 23:02:30,275 DEBUG [RS:0;quirinus:56476.logRoller]
regionserver.LogRoller(87): Hlog roll period 4000ms elapsed
{code}
The interval between two successive periodic rolls was ~1.5s longer than
LOG_ROLL_PERIOD (4s)
1.5s * 4 (minRolls-1) > 4s (LOG_ROLL_PERIOD)
This led to the test failure:
{code}
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertFalse(Assert.java:64)
at org.junit.Assert.assertFalse(Assert.java:74)
at
org.apache.hadoop.hbase.regionserver.wal.TestLogRollPeriod.checkMinLogRolls(TestLogRollPeriod.java:168)
at
org.apache.hadoop.hbase.regionserver.wal.TestLogRollPeriod.testWithEdits(TestLogRollPeriod.java:130)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10271) [regression] Cannot use the wildcard address since HBASE-9593
[
https://issues.apache.org/jira/browse/HBASE-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894002#comment-13894002
]
stack commented on HBASE-10271:
---
Moved it out of 0.96.2. No patch.
> [regression] Cannot use the wildcard address since HBASE-9593
> -
>
> Key: HBASE-10271
> URL: https://issues.apache.org/jira/browse/HBASE-10271
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.13, 0.96.1
>Reporter: Jean-Daniel Cryans
>Priority: Critical
> Fix For: 0.99.0
>
> Attachments: HBASE-10271.patch
>
>
> HBASE-9593 moved the creation of the ephemeral znode earlier in the region
> server startup process such that we don't have access to the ServerName from
> the Master's POV. HRS.getMyEphemeralNodePath() calls HRS.getServerName()
> which at that point will return this.isa.getHostName(). If you set
> hbase.regionserver.ipc.address to 0.0.0.0, you will create a znode with that
> address.
> What happens next is that the RS will report for duty correctly but the
> master will do this:
> {noformat}
> 2014-01-02 11:45:49,498 INFO [master:172.21.3.117:6]
> master.ServerManager: Registering server=0:0:0:0:0:0:0:0%0,60020,1388691892014
> 2014-01-02 11:45:49,498 INFO [master:172.21.3.117:6] master.HMaster:
> Registered server found up in zk but who has not yet reported in:
> 0:0:0:0:0:0:0:0%0,60020,1388691892014
> {noformat}
> The cluster is then unusable.
> I think a better solution is to track the heartbeats for the region servers
> and expire those that haven't checked-in for some time. The 0.89-fb branch
> has this concept, and they also use it to detect rack failures:
> https://github.com/apache/hbase/blob/0.89-fb/src/main/java/org/apache/hadoop/hbase/master/ServerManager.java#L1224.
> In this jira's scope I would just add the heartbeat tracking and add a unit
> test for the wildcard address.
> What do you think [~rajesh23]?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10271) [regression] Cannot use the wildcard address since HBASE-9593
[
https://issues.apache.org/jira/browse/HBASE-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-10271:
--
Fix Version/s: (was: 0.96.2)
> [regression] Cannot use the wildcard address since HBASE-9593
> -
>
> Key: HBASE-10271
> URL: https://issues.apache.org/jira/browse/HBASE-10271
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.13, 0.96.1
>Reporter: Jean-Daniel Cryans
>Priority: Critical
> Fix For: 0.99.0
>
> Attachments: HBASE-10271.patch
>
>
> HBASE-9593 moved the creation of the ephemeral znode earlier in the region
> server startup process such that we don't have access to the ServerName from
> the Master's POV. HRS.getMyEphemeralNodePath() calls HRS.getServerName()
> which at that point will return this.isa.getHostName(). If you set
> hbase.regionserver.ipc.address to 0.0.0.0, you will create a znode with that
> address.
> What happens next is that the RS will report for duty correctly but the
> master will do this:
> {noformat}
> 2014-01-02 11:45:49,498 INFO [master:172.21.3.117:6]
> master.ServerManager: Registering server=0:0:0:0:0:0:0:0%0,60020,1388691892014
> 2014-01-02 11:45:49,498 INFO [master:172.21.3.117:6] master.HMaster:
> Registered server found up in zk but who has not yet reported in:
> 0:0:0:0:0:0:0:0%0,60020,1388691892014
> {noformat}
> The cluster is then unusable.
> I think a better solution is to track the heartbeats for the region servers
> and expire those that haven't checked-in for some time. The 0.89-fb branch
> has this concept, and they also use it to detect rack failures:
> https://github.com/apache/hbase/blob/0.89-fb/src/main/java/org/apache/hadoop/hbase/master/ServerManager.java#L1224.
> In this jira's scope I would just add the heartbeat tracking and add a unit
> test for the wildcard address.
> What do you think [~rajesh23]?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10303) Have snappy support properly documented would be helpful to hadoop and hbase users
[ https://issues.apache.org/jira/browse/HBASE-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-10303: -- Priority: Major (was: Blocker) Fix Version/s: (was: 0.96.2) I made an edit to catch most of Rural's notes in the snappy section. I'm not resolving because this section could get a redo/update so less likely others run into the same experience Rural had. Moving out of 0.96.2. > Have snappy support properly documented would be helpful to hadoop and hbase > users > -- > > Key: HBASE-10303 > URL: https://issues.apache.org/jira/browse/HBASE-10303 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Rural Hunter > > The currentl document for configuring snappy > support(http://hbase.apache.org/book/snappy.compression.html) is not complete > and it's a bit obscure. IMO, there are several improvments can be made: > 1. Describe the relationship among hadoop,hbase,snappy. Is the snappy > actually needed by hadoop hdfs or hbase itself? That's to make clear if you > need to configure snappy support in hbase or hadoop. > 2. It didn't mention the default hadoop binary package is compiled without > snappy support and you need to compile it with snappy option manually. > Actually it didn't work with any native libs on 64 bits OS as the > libhadoop.so in the binary package is only for 32 bits OS(this of course is a > hadoop issue not hbase. but it's good to mention it.). > 3. In my experience, I actually need to install both snappy and > hadoop-snappy. So the doc lack of the steps to install hadoop-snappy. > 4. During my set up, I found difference where hadoop and hbase to pick up the > native lib files. hadoop picks those files in ./lib while hbase picks in > ./lib/[PLATFORM]. If it's correct, it can also be mentioned. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[
https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893995#comment-13893995
]
Hadoop QA commented on HBASE-10479:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12627501/HBASE-10479.patch
against trunk revision .
ATTACHMENT ID: 12627501
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified tests.
{color:red}-1 hadoop1.0{color}. The patch failed to compile against the
hadoop 1.0 profile.
Here is snippet of errors:
{code}[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile)
on project hbase-client: Compilation failure: Compilation failure:
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java:[121,12]
cannot find symbol
[ERROR] symbol : class HConnectionInternal
[ERROR] location: class org.apache.hadoop.hbase.client.HTable
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java:[316,43]
cannot find symbol
[ERROR] symbol : class HConnectionInternal
--
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile)
on project hbase-client: Compilation failure
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
--
Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation
failure
at
org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:729)
at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more{code}
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8617//console
This message is automatically generated.
> HConnection interface is public but is used internally, and contains a bunch
> of methods
> ---
>
> Key: HBASE-10479
> URL: https://issues.apache.org/jira/browse/HBASE-10479
> Project: HBase
> Issue Type: Improvement
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
> Attachments: HBASE-10479.patch
>
>
> HConnection has too many methods for a public interface, and some of these
> should not be public.
> It is used extensively for internal purposes, so we keep adding methods to it
> that may not make sense for public interface.
> The idea is to create a separate internal interface inheriting HConnection,
> copy some methods to it and deprecate them on HConnection. New methods for
> internal use would be added to new interface; the deprecated methods would
> eventually be removed from public interface.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (HBASE-10363) [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23 profiles.
[
https://issues.apache.org/jira/browse/HBASE-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893984#comment-13893984
]
Jonathan Hsieh edited comment on HBASE-10363 at 2/6/14 11:40 PM:
-
since this is 0.94 only, lgtm. (otherwise we'd go into those hadoop-compat
modules).
was (Author: jmhsieh):
since this is 0.94 only, lgtm.
> [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23
> profiles.
> ---
>
> Key: HBASE-10363
> URL: https://issues.apache.org/jira/browse/HBASE-10363
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.15
>Reporter: Jonathan Hsieh
>Priority: Critical
> Fix For: 0.94.17
>
> Attachments: 10363.txt
>
>
> From tip of 0.94 and from 0.94.15.
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=2.0
> -Dtest=TestInputSampler,TestInputSamplerTool -PlocalTests
> ...
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool
> Tests run: 4, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 3.718 sec <<<
> FAILURE!
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.666 sec <<<
> FAILURE!
> Results :
> Tests in error:
>
> testSplitInterval(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitRamdom(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSample(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
>
> testIntervalSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
> Tests run: 6, Failures: 0, Errors: 5, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10363) [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23 profiles.
[
https://issues.apache.org/jira/browse/HBASE-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893984#comment-13893984
]
Jonathan Hsieh commented on HBASE-10363:
since this is 0.94 only, lgtm.
> [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23
> profiles.
> ---
>
> Key: HBASE-10363
> URL: https://issues.apache.org/jira/browse/HBASE-10363
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.15
>Reporter: Jonathan Hsieh
>Priority: Critical
> Fix For: 0.94.17
>
> Attachments: 10363.txt
>
>
> From tip of 0.94 and from 0.94.15.
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=2.0
> -Dtest=TestInputSampler,TestInputSamplerTool -PlocalTests
> ...
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool
> Tests run: 4, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 3.718 sec <<<
> FAILURE!
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.666 sec <<<
> FAILURE!
> Results :
> Tests in error:
>
> testSplitInterval(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitRamdom(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSample(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
>
> testIntervalSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
> Tests run: 6, Failures: 0, Errors: 5, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10169) Batch coprocessor
[ https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Helmling updated HBASE-10169: -- Attachment: HBASE-10169-alternate-3.patch Updated patch to account for the AsyncProcess refactoring in HBASE-10277. > Batch coprocessor > - > > Key: HBASE-10169 > URL: https://issues.apache.org/jira/browse/HBASE-10169 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 0.99.0 >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: Batch Coprocessor Design Document.docx, > HBASE-10169-V2.patch, HBASE-10169-V3.patch, HBASE-10169-V3.patch, > HBASE-10169-V4.patch, HBASE-10169-V5.patch, HBASE-10169-alternate-2.patch, > HBASE-10169-alternate-3.patch, HBASE-10169-alternate.patch, HBASE-10169.patch > > > This is designed to improve the coprocessor invocation in the client side. > Currently the coprocessor invocation is to send a call to each region. If > there’s one region server, and 100 regions are located in this server, each > coprocessor invocation will send 100 calls, each call uses a single thread in > the client side. The threads will run out soon when the coprocessor > invocations are heavy. > In this design, all the calls to the same region server will be grouped into > one in a single coprocessor invocation. This call will be spread into each > region in the server side. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10249) TestReplicationSyncUpTool fails because failover takes too long
[ https://issues.apache.org/jira/browse/HBASE-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893981#comment-13893981 ] Ted Yu commented on HBASE-10249: Pardon me, it failed lately: https://builds.apache.org/job/HBase-TRUNK/4895/testReport/junit/org.apache.hadoop.hbase.replication/TestReplicationSyncUpTool/testSyncUpTool/ > TestReplicationSyncUpTool fails because failover takes too long > --- > > Key: HBASE-10249 > URL: https://issues.apache.org/jira/browse/HBASE-10249 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Jean-Daniel Cryans > Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17 > > Attachments: HBASE-10249-0.94-v0.patch, HBASE-10249-0.94-v1.patch, > HBASE-10249-trunk-v0.patch, HBASE-10249-trunk-v1.patch > > > New issue to keep track of this. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[ https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893974#comment-13893974 ] Sergey Shelukhin commented on HBASE-10479: -- Update. The "new model" is HConnection as a "cluster" interface. The only thing it should do is get tables (and HBaseAdmin?). > HConnection interface is public but is used internally, and contains a bunch > of methods > --- > > Key: HBASE-10479 > URL: https://issues.apache.org/jira/browse/HBASE-10479 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-10479.patch > > > HConnection has too many methods for a public interface, and some of these > should not be public. > It is used extensively for internal purposes, so we keep adding methods to it > that may not make sense for public interface. > The idea is to create a separate internal interface inheriting HConnection, > copy some methods to it and deprecate them on HConnection. New methods for > internal use would be added to new interface; the deprecated methods would > eventually be removed from public interface. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[ https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-10479: - Attachment: HBASE-10479.patch Here's a patch. It deprecates some stuff. It is questionable what should be deprecated... I like hiding stuff. I deprecated all the cache related methods, so they should now be accessed only thru HConnectionInternal; I didn't yet, but after discussing with [~enis] I am also going to hide all blockinginterface accessors (getMaster, getAdmin, etc.) and move them to internal. Users should not be calling RPCs directly, they should use the client library. > HConnection interface is public but is used internally, and contains a bunch > of methods > --- > > Key: HBASE-10479 > URL: https://issues.apache.org/jira/browse/HBASE-10479 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-10479.patch > > > HConnection has too many methods for a public interface, and some of these > should not be public. > It is used extensively for internal purposes, so we keep adding methods to it > that may not make sense for public interface. > The idea is to create a separate internal interface inheriting HConnection, > copy some methods to it and deprecate them on HConnection. New methods for > internal use would be added to new interface; the deprecated methods would > eventually be removed from public interface. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[ https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-10479: - Status: Patch Available (was: Open) > HConnection interface is public but is used internally, and contains a bunch > of methods > --- > > Key: HBASE-10479 > URL: https://issues.apache.org/jira/browse/HBASE-10479 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-10479.patch > > > HConnection has too many methods for a public interface, and some of these > should not be public. > It is used extensively for internal purposes, so we keep adding methods to it > that may not make sense for public interface. > The idea is to create a separate internal interface inheriting HConnection, > copy some methods to it and deprecate them on HConnection. New methods for > internal use would be added to new interface; the deprecated methods would > eventually be removed from public interface. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10478) Hbase book presentations page has broken link
[ https://issues.apache.org/jira/browse/HBASE-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893963#comment-13893963 ] Hudson commented on HBASE-10478: FAILURE: Integrated in HBase-TRUNK #4895 (See [https://builds.apache.org/job/HBase-TRUNK/4895/]) HBASE-10478 [docs] HBase book presentations page has broken link (Vivek Ganesan) (jmhsieh: rev 1565427) * /hbase/trunk/src/main/docbkx/book.xml > Hbase book presentations page has broken link > - > > Key: HBASE-10478 > URL: https://issues.apache.org/jira/browse/HBASE-10478 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Vivek Ganesan >Assignee: Vivek Ganesan >Priority: Minor > Fix For: 0.99.0 > > Attachments: HBASE-10478.patch > > > Hbase book page http://hbase.apache.org/book/other.info.pres.html has a link > "Advanced HBase Schema Design". This presentation seems to have been moved > to a new URL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10169) Batch coprocessor
[ https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893914#comment-13893914 ] Gary Helmling commented on HBASE-10169: --- [~sershe] Thanks for the info. Looking over the AsyncProcess changes, it shouldn't be hard to adapt this patch to use them. I don't really need AsyncProcessCallback specifically, I was more using it due to the old API. > Batch coprocessor > - > > Key: HBASE-10169 > URL: https://issues.apache.org/jira/browse/HBASE-10169 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 0.99.0 >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: Batch Coprocessor Design Document.docx, > HBASE-10169-V2.patch, HBASE-10169-V3.patch, HBASE-10169-V3.patch, > HBASE-10169-V4.patch, HBASE-10169-V5.patch, HBASE-10169-alternate-2.patch, > HBASE-10169-alternate.patch, HBASE-10169.patch > > > This is designed to improve the coprocessor invocation in the client side. > Currently the coprocessor invocation is to send a call to each region. If > there’s one region server, and 100 regions are located in this server, each > coprocessor invocation will send 100 calls, each call uses a single thread in > the client side. The threads will run out soon when the coprocessor > invocations are heavy. > In this design, all the calls to the same region server will be grouped into > one in a single coprocessor invocation. This call will be spread into each > region in the server side. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10169) Batch coprocessor
[ https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893911#comment-13893911 ] Ted Yu commented on HBASE-10169: I went through Gary's patch - it is clean. Good work. > Batch coprocessor > - > > Key: HBASE-10169 > URL: https://issues.apache.org/jira/browse/HBASE-10169 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 0.99.0 >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: Batch Coprocessor Design Document.docx, > HBASE-10169-V2.patch, HBASE-10169-V3.patch, HBASE-10169-V3.patch, > HBASE-10169-V4.patch, HBASE-10169-V5.patch, HBASE-10169-alternate-2.patch, > HBASE-10169-alternate.patch, HBASE-10169.patch > > > This is designed to improve the coprocessor invocation in the client side. > Currently the coprocessor invocation is to send a call to each region. If > there’s one region server, and 100 regions are located in this server, each > coprocessor invocation will send 100 calls, each call uses a single thread in > the client side. The threads will run out soon when the coprocessor > invocations are heavy. > In this design, all the calls to the same region server will be grouped into > one in a single coprocessor invocation. This call will be spread into each > region in the server side. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10337) HTable.get() uninteruptible
[ https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893900#comment-13893900 ] Hudson commented on HBASE-10337: FAILURE: Integrated in HBase-0.98 #137 (See [https://builds.apache.org/job/HBase-0.98/137/]) HBASE-10477 Regression from HBASE-10337 (nkeywal: rev 1565366) * /hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java > HTable.get() uninteruptible > --- > > Key: HBASE-10337 > URL: https://issues.apache.org/jira/browse/HBASE-10337 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1 >Reporter: Jonathan Leech >Assignee: Nicolas Liochon > Fix For: 0.98.0, 0.99.0 > > Attachments: 10337-addendum.patch, 10337.v1.patch, 10337.v2.patch > > > I've got a stuck thread on HTable.get() that can't be interrupted, looks like > its designed to be interruptible but can't be in interrupted in practice due > to while loop. > The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line > 981, it catches InterruptedException then goes right back to waiting due to > the while loop. > It looks like future versions of the client (.95+) are significantly > different and might not have this problem... Not sure about release schedules > etc. or if this version is still getting patched. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10477) Regression from HBASE-10337
[ https://issues.apache.org/jira/browse/HBASE-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893901#comment-13893901 ] Hudson commented on HBASE-10477: FAILURE: Integrated in HBase-0.98 #137 (See [https://builds.apache.org/job/HBase-0.98/137/]) HBASE-10477 Regression from HBASE-10337 (nkeywal: rev 1565366) * /hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java > Regression from HBASE-10337 > --- > > Key: HBASE-10477 > URL: https://issues.apache.org/jira/browse/HBASE-10477 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.99.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon >Priority: Critical > Fix For: 0.98.0, 0.99.0 > > Attachments: 10477.v1.patch > > > a piece of code that should not have make it... > ping [~andrew.purt...@gmail.com] -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10475) TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent lease removal
[
https://issues.apache.org/jira/browse/HBASE-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893899#comment-13893899
]
Hudson commented on HBASE-10475:
FAILURE: Integrated in HBase-0.98 #137 (See
[https://builds.apache.org/job/HBase-0.98/137/])
HBASE-10475 TestRegionServerCoprocessorExceptionWithAbort may timeout due to
concurrent lease removal (tedyu: rev 1565386)
*
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/SimpleRegionObserver.java
> TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent
> lease removal
> -
>
> Key: HBASE-10475
> URL: https://issues.apache.org/jira/browse/HBASE-10475
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Minor
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10475-v1.txt, 10475-v2.txt,
> org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort-output.txt
>
>
> I got the following test failure:
> {code}
> testExceptionFromCoprocessorDuringPut(org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort)
> Time elapsed: 0.049 sec <<< ERROR!
> java.lang.Exception: test timed out after 6 milliseconds
> at java.lang.Object.wait(Native Method)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForNextTaskDone(AsyncProcess.java:837)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForMaximumCurrentTasks(AsyncProcess.java:863)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitUntilDone(AsyncProcess.java:876)
> at
> org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:945)
> at
> org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1225)
> at org.apache.hadoop.hbase.client.HTable.put(HTable.java:887)
> at
> org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort.testExceptionFromCoprocessorDuringPut(TestRegionServerCoprocessorExceptionWithAbort.java:106)
> {code}
> This was due to unexpected LeaseException bringing down region server:
> {code}
> 2014-02-05 19:28:24,752 ERROR [RS_OPEN_REGION-kiyo:56349-1]
> coprocessor.CoprocessorHost(760): The coprocessor
> org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort$BuggyRegionObserver
> threw an unexpected exception
> org.apache.hadoop.hbase.regionserver.LeaseException: lease 'x' does not exist
> at
> org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:221)
> at
> org.apache.hadoop.hbase.regionserver.Leases.cancelLease(Leases.java:206)
> at
> org.apache.hadoop.hbase.coprocessor.SimpleRegionObserver.start(SimpleRegionObserver.java:140)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.startup(CoprocessorHost.java:651)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadInstance(CoprocessorHost.java:261)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10169) Batch coprocessor
[
https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893892#comment-13893892
]
Hadoop QA commented on HBASE-10169:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12627472/HBASE-10169-alternate-2.patch
against trunk revision .
ATTACHMENT ID: 12627472
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 17 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/8616//console
This message is automatically generated.
> Batch coprocessor
> -
>
> Key: HBASE-10169
> URL: https://issues.apache.org/jira/browse/HBASE-10169
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Affects Versions: 0.99.0
>Reporter: Jingcheng Du
>Assignee: Jingcheng Du
> Attachments: Batch Coprocessor Design Document.docx,
> HBASE-10169-V2.patch, HBASE-10169-V3.patch, HBASE-10169-V3.patch,
> HBASE-10169-V4.patch, HBASE-10169-V5.patch, HBASE-10169-alternate-2.patch,
> HBASE-10169-alternate.patch, HBASE-10169.patch
>
>
> This is designed to improve the coprocessor invocation in the client side.
> Currently the coprocessor invocation is to send a call to each region. If
> there’s one region server, and 100 regions are located in this server, each
> coprocessor invocation will send 100 calls, each call uses a single thread in
> the client side. The threads will run out soon when the coprocessor
> invocations are heavy.
> In this design, all the calls to the same region server will be grouped into
> one in a single coprocessor invocation. This call will be spread into each
> region in the server side.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[ https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893880#comment-13893880 ] Sergey Shelukhin commented on HBASE-10479: -- We have a problem with public ctors/factory methods being passed HConnection. There cannot be changed to accept HCInternal because the whole point is for client to not have HCInternal. So there will be some casts. > HConnection interface is public but is used internally, and contains a bunch > of methods > --- > > Key: HBASE-10479 > URL: https://issues.apache.org/jira/browse/HBASE-10479 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > > HConnection has too many methods for a public interface, and some of these > should not be public. > It is used extensively for internal purposes, so we keep adding methods to it > that may not make sense for public interface. > The idea is to create a separate internal interface inheriting HConnection, > copy some methods to it and deprecate them on HConnection. New methods for > internal use would be added to new interface; the deprecated methods would > eventually be removed from public interface. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10169) Batch coprocessor
[ https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893879#comment-13893879 ] Sergey Shelukhin commented on HBASE-10169: -- It was removed for lack of need (at least in trunk code then). As far as I see, the attached patch uses it to check for non-retriable exception (not needed, AP already does that) and to call batch callback (which is retained, and also already called by AP on success). Results/errors can be retrieved directly from AP submit/submitAll call result, or from AP itself. If there's scenario for user callback I guess we can re-add it in some form... > Batch coprocessor > - > > Key: HBASE-10169 > URL: https://issues.apache.org/jira/browse/HBASE-10169 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 0.99.0 >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: Batch Coprocessor Design Document.docx, > HBASE-10169-V2.patch, HBASE-10169-V3.patch, HBASE-10169-V3.patch, > HBASE-10169-V4.patch, HBASE-10169-V5.patch, HBASE-10169-alternate-2.patch, > HBASE-10169-alternate.patch, HBASE-10169.patch > > > This is designed to improve the coprocessor invocation in the client side. > Currently the coprocessor invocation is to send a call to each region. If > there’s one region server, and 100 regions are located in this server, each > coprocessor invocation will send 100 calls, each call uses a single thread in > the client side. The threads will run out soon when the coprocessor > invocations are heavy. > In this design, all the calls to the same region server will be grouped into > one in a single coprocessor invocation. This call will be spread into each > region in the server side. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10169) Batch coprocessor
[ https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893865#comment-13893865 ] Gary Helmling commented on HBASE-10169: --- [~yuzhih...@gmail.com] What was it replaced by? > Batch coprocessor > - > > Key: HBASE-10169 > URL: https://issues.apache.org/jira/browse/HBASE-10169 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 0.99.0 >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: Batch Coprocessor Design Document.docx, > HBASE-10169-V2.patch, HBASE-10169-V3.patch, HBASE-10169-V3.patch, > HBASE-10169-V4.patch, HBASE-10169-V5.patch, HBASE-10169-alternate-2.patch, > HBASE-10169-alternate.patch, HBASE-10169.patch > > > This is designed to improve the coprocessor invocation in the client side. > Currently the coprocessor invocation is to send a call to each region. If > there’s one region server, and 100 regions are located in this server, each > coprocessor invocation will send 100 calls, each call uses a single thread in > the client side. The threads will run out soon when the coprocessor > invocations are heavy. > In this design, all the calls to the same region server will be grouped into > one in a single coprocessor invocation. This call will be spread into each > region in the server side. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10169) Batch coprocessor
[ https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893863#comment-13893863 ] Ted Yu commented on HBASE-10169: AsyncProcess#AsyncProcessCallback was removed by HBASE-10277 > Batch coprocessor > - > > Key: HBASE-10169 > URL: https://issues.apache.org/jira/browse/HBASE-10169 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 0.99.0 >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: Batch Coprocessor Design Document.docx, > HBASE-10169-V2.patch, HBASE-10169-V3.patch, HBASE-10169-V3.patch, > HBASE-10169-V4.patch, HBASE-10169-V5.patch, HBASE-10169-alternate-2.patch, > HBASE-10169-alternate.patch, HBASE-10169.patch > > > This is designed to improve the coprocessor invocation in the client side. > Currently the coprocessor invocation is to send a call to each region. If > there’s one region server, and 100 regions are located in this server, each > coprocessor invocation will send 100 calls, each call uses a single thread in > the client side. The threads will run out soon when the coprocessor > invocations are heavy. > In this design, all the calls to the same region server will be grouped into > one in a single coprocessor invocation. This call will be spread into each > region in the server side. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-9459) Backport 8534 "Fix coverage for org.apache.hadoop.hbase.mapreduce" to 0.94
[ https://issues.apache.org/jira/browse/HBASE-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-9459: - Fix Version/s: (was: 0.94.17) 0.94.18 > Backport 8534 "Fix coverage for org.apache.hadoop.hbase.mapreduce" to 0.94 > -- > > Key: HBASE-9459 > URL: https://issues.apache.org/jira/browse/HBASE-9459 > Project: HBase > Issue Type: Test > Components: mapreduce, test >Reporter: Nick Dimiduk >Assignee: Ivan A. Veselovsky > Fix For: 0.94.18 > > Attachments: HBASE-9459-0.94--n3.patch > > > Do you want this test update backported? See HBASE-8534 for a 0.94 patch. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10340) [BACKPORT] HBASE-9892 Add info port to ServerName to support multi instances in a node
[ https://issues.apache.org/jira/browse/HBASE-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893840#comment-13893840 ] Enis Soztutar commented on HBASE-10340: --- >From what I remember form the review, it should be fine. We had to keep BC for >rolling upgrades between 0.96 and 0.98, so 0.96.x -> 0.96.2 should work >equally good. Don't forget to backport HBASE-10334 as well after this. > [BACKPORT] HBASE-9892 Add info port to ServerName to support multi instances > in a node > -- > > Key: HBASE-10340 > URL: https://issues.apache.org/jira/browse/HBASE-10340 > Project: HBase > Issue Type: Bug >Reporter: stack > Fix For: 0.96.2, 0.94.17 > > > Backport this patch after testing it does not break anything. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10363) [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23 profiles.
[
https://issues.apache.org/jira/browse/HBASE-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893839#comment-13893839
]
Lars Hofhansl commented on HBASE-10363:
---
Both tests pass with Hadoop 1 and 2 with this patch.
> [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23
> profiles.
> ---
>
> Key: HBASE-10363
> URL: https://issues.apache.org/jira/browse/HBASE-10363
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.15
>Reporter: Jonathan Hsieh
>Priority: Critical
> Fix For: 0.94.17
>
> Attachments: 10363.txt
>
>
> From tip of 0.94 and from 0.94.15.
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=2.0
> -Dtest=TestInputSampler,TestInputSamplerTool -PlocalTests
> ...
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool
> Tests run: 4, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 3.718 sec <<<
> FAILURE!
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.666 sec <<<
> FAILURE!
> Results :
> Tests in error:
>
> testSplitInterval(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitRamdom(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSample(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
>
> testIntervalSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
> Tests run: 6, Failures: 0, Errors: 5, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10337) HTable.get() uninteruptible
[ https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893836#comment-13893836 ] Hudson commented on HBASE-10337: SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #126 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/126/]) HBASE-10477 Regression from HBASE-10337 (nkeywal: rev 1565366) * /hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java > HTable.get() uninteruptible > --- > > Key: HBASE-10337 > URL: https://issues.apache.org/jira/browse/HBASE-10337 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1 >Reporter: Jonathan Leech >Assignee: Nicolas Liochon > Fix For: 0.98.0, 0.99.0 > > Attachments: 10337-addendum.patch, 10337.v1.patch, 10337.v2.patch > > > I've got a stuck thread on HTable.get() that can't be interrupted, looks like > its designed to be interruptible but can't be in interrupted in practice due > to while loop. > The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line > 981, it catches InterruptedException then goes right back to waiting due to > the while loop. > It looks like future versions of the client (.95+) are significantly > different and might not have this problem... Not sure about release schedules > etc. or if this version is still getting patched. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10363) [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23 profiles.
[
https://issues.apache.org/jira/browse/HBASE-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-10363:
--
Attachment: 10363.txt
Here's a patch.
Checks whether TaskAttemptContext is an interface first (so there's no
performance penalty in Hadoop 1.x). If it is it tries to create a
TaskAttemptContextImpl (Hadoop 2.x).
> [0.94] TestInputSampler and TestInputSamplerTool fail under hadoop 2.0/23
> profiles.
> ---
>
> Key: HBASE-10363
> URL: https://issues.apache.org/jira/browse/HBASE-10363
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.15
>Reporter: Jonathan Hsieh
>Priority: Critical
> Fix For: 0.94.17
>
> Attachments: 10363.txt
>
>
> From tip of 0.94 and from 0.94.15.
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=2.0
> -Dtest=TestInputSampler,TestInputSamplerTool -PlocalTests
> ...
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool
> Tests run: 4, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 3.718 sec <<<
> FAILURE!
> Running org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.666 sec <<<
> FAILURE!
> Results :
> Tests in error:
>
> testSplitInterval(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitRamdom(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSample(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSamplerTool):
> Failed getting constructor
>
> testSplitSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
>
> testIntervalSampler(org.apache.hadoop.hbase.mapreduce.hadoopbackport.TestInputSampler):
> Failed getting constructor
> Tests run: 6, Failures: 0, Errors: 5, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10477) Regression from HBASE-10337
[ https://issues.apache.org/jira/browse/HBASE-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893837#comment-13893837 ] Hudson commented on HBASE-10477: SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #126 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/126/]) HBASE-10477 Regression from HBASE-10337 (nkeywal: rev 1565366) * /hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java > Regression from HBASE-10337 > --- > > Key: HBASE-10477 > URL: https://issues.apache.org/jira/browse/HBASE-10477 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.99.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon >Priority: Critical > Fix For: 0.98.0, 0.99.0 > > Attachments: 10477.v1.patch > > > a piece of code that should not have make it... > ping [~andrew.purt...@gmail.com] -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[ https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893830#comment-13893830 ] Enis Soztutar commented on HBASE-10479: --- We need to fix this sooner rather than later. HBASE-10347 already deprecates most of the cache related methods and region location related methods there. These should go into the new interface. It seems that in HConnection, by convention, we marked client-facing methods as public, and not-client-facing methods as package protected. However, there is no concept of package protected in interfaces in Java. We should start by deprecating every method not declared public in HC and move it to the new class. > HConnection interface is public but is used internally, and contains a bunch > of methods > --- > > Key: HBASE-10479 > URL: https://issues.apache.org/jira/browse/HBASE-10479 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > > HConnection has too many methods for a public interface, and some of these > should not be public. > It is used extensively for internal purposes, so we keep adding methods to it > that may not make sense for public interface. > The idea is to create a separate internal interface inheriting HConnection, > copy some methods to it and deprecate them on HConnection. New methods for > internal use would be added to new interface; the deprecated methods would > eventually be removed from public interface. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10169) Batch coprocessor
[ https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Helmling updated HBASE-10169: -- Attachment: HBASE-10169-alternate-2.patch Attaching a new patch: * Slight cleanup of args and docs for new HTableInterface methods * Fix use of HashMap in TestBatchCoprocessorEndpoint * Fix up HadoopQA issues from last patch > Batch coprocessor > - > > Key: HBASE-10169 > URL: https://issues.apache.org/jira/browse/HBASE-10169 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 0.99.0 >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: Batch Coprocessor Design Document.docx, > HBASE-10169-V2.patch, HBASE-10169-V3.patch, HBASE-10169-V3.patch, > HBASE-10169-V4.patch, HBASE-10169-V5.patch, HBASE-10169-alternate-2.patch, > HBASE-10169-alternate.patch, HBASE-10169.patch > > > This is designed to improve the coprocessor invocation in the client side. > Currently the coprocessor invocation is to send a call to each region. If > there’s one region server, and 100 regions are located in this server, each > coprocessor invocation will send 100 calls, each call uses a single thread in > the client side. The threads will run out soon when the coprocessor > invocations are heavy. > In this design, all the calls to the same region server will be grouped into > one in a single coprocessor invocation. This call will be spread into each > region in the server side. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10185) HBaseClient retries even though a DoNotRetryException was thrown
[
https://issues.apache.org/jira/browse/HBASE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893798#comment-13893798
]
Nicolas Liochon commented on HBASE-10185:
-
Ok, I'm going to double check the patch and "officially" submit it them. This
part is a little bit scary as not all path are explicitly synchronized even if
they are used in a multithreaded context...
> HBaseClient retries even though a DoNotRetryException was thrown
>
>
> Key: HBASE-10185
> URL: https://issues.apache.org/jira/browse/HBASE-10185
> Project: HBase
> Issue Type: Bug
> Components: IPC/RPC
>Affects Versions: 0.94.12, 0.99.0
>Reporter: Samarth
> Fix For: 0.99.0
>
> Attachments: 10185.v1.patch
>
>
> Throwing a DoNotRetryIOException inside Writable.write(Dataoutput) method
> doesn't prevent HBase from retrying. Debugging the code locally, I figured
> that the bug lies in the way HBaseClient simply throws an IOException when it
> sees that a connection has been closed unexpectedly.
> Method:
> public Writable call(Writable param, InetSocketAddress addr,
>Class protocol,
>User ticket, int rpcTimeout)
> Excerpt of code where the bug is present:
> while (!call.done) {
> if (connection.shouldCloseConnection.get()) {
> throw new IOException("Unexpected closed connection");
> }
> Throwing this IOException causes the ServerCallable.translateException(t) to
> be a no-op resulting in HBase retrying.
> From my limited view and understanding of the code, one way I could think of
> handling this is by looking at the closeConnection member variable of a
> connection to determine what kind of exception should be thrown.
> Specifically, when a connection is closed, the current code does this:
> protected synchronized void markClosed(IOException e) {
> if (shouldCloseConnection.compareAndSet(false, true)) {
> closeException = e;
> notifyAll();
> }
> }
> Within HBaseClient's call method, the code could possibly be modified to:
> while (!call.done) {
> if (connection.shouldCloseConnection.get() ) {
> if(connection.closeException instanceof
> DoNotRetryIOException) {
> throw closeException;
> }
> throw new IOException("Unexpected closed connection");
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (HBASE-10185) HBaseClient retries even though a DoNotRetryException was thrown
[
https://issues.apache.org/jira/browse/HBASE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Liochon reassigned HBASE-10185:
---
Assignee: Nicolas Liochon
> HBaseClient retries even though a DoNotRetryException was thrown
>
>
> Key: HBASE-10185
> URL: https://issues.apache.org/jira/browse/HBASE-10185
> Project: HBase
> Issue Type: Bug
> Components: IPC/RPC
>Affects Versions: 0.94.12, 0.99.0
>Reporter: Samarth
>Assignee: Nicolas Liochon
> Fix For: 0.99.0
>
> Attachments: 10185.v1.patch
>
>
> Throwing a DoNotRetryIOException inside Writable.write(Dataoutput) method
> doesn't prevent HBase from retrying. Debugging the code locally, I figured
> that the bug lies in the way HBaseClient simply throws an IOException when it
> sees that a connection has been closed unexpectedly.
> Method:
> public Writable call(Writable param, InetSocketAddress addr,
>Class protocol,
>User ticket, int rpcTimeout)
> Excerpt of code where the bug is present:
> while (!call.done) {
> if (connection.shouldCloseConnection.get()) {
> throw new IOException("Unexpected closed connection");
> }
> Throwing this IOException causes the ServerCallable.translateException(t) to
> be a no-op resulting in HBase retrying.
> From my limited view and understanding of the code, one way I could think of
> handling this is by looking at the closeConnection member variable of a
> connection to determine what kind of exception should be thrown.
> Specifically, when a connection is closed, the current code does this:
> protected synchronized void markClosed(IOException e) {
> if (shouldCloseConnection.compareAndSet(false, true)) {
> closeException = e;
> notifyAll();
> }
> }
> Within HBaseClient's call method, the code could possibly be modified to:
> while (!call.done) {
> if (connection.shouldCloseConnection.get() ) {
> if(connection.closeException instanceof
> DoNotRetryIOException) {
> throw closeException;
> }
> throw new IOException("Unexpected closed connection");
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[ https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin reassigned HBASE-10479: Assignee: Sergey Shelukhin > HConnection interface is public but is used internally, and contains a bunch > of methods > --- > > Key: HBASE-10479 > URL: https://issues.apache.org/jira/browse/HBASE-10479 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > > HConnection has too many methods for a public interface, and some of these > should not be public. > It is used extensively for internal purposes, so we keep adding methods to it > that may not make sense for public interface. > The idea is to create a separate internal interface inheriting HConnection, > copy some methods to it and deprecate them on HConnection. New methods for > internal use would be added to new interface; the deprecated methods would > eventually be removed from public interface. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[ https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893781#comment-13893781 ] Sergey Shelukhin commented on HBASE-10479: -- [~mbertozzi] hmm? :) > HConnection interface is public but is used internally, and contains a bunch > of methods > --- > > Key: HBASE-10479 > URL: https://issues.apache.org/jira/browse/HBASE-10479 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > > HConnection has too many methods for a public interface, and some of these > should not be public. > It is used extensively for internal purposes, so we keep adding methods to it > that may not make sense for public interface. > The idea is to create a separate internal interface inheriting HConnection, > copy some methods to it and deprecate them on HConnection. New methods for > internal use would be added to new interface; the deprecated methods would > eventually be removed from public interface. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10356) Failover RPC's for multi-get
[ https://issues.apache.org/jira/browse/HBASE-10356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893749#comment-13893749 ] stack commented on HBASE-10356: --- Can we fix the naming? An Action instance with a method named getAction is confusing (not you I know...) Do I have the model wrong then? This Action is for accounting on how this 'Action' did in the Multi request, right? My thinking is that server and region accounting is done outside of the Action usually. I'd think which replica would be done there w/o needing to mark this index on the Multi call. bq. Second, AP currently already manages finding the locations and grouping of request, it wouldn't make sense to have another external place to manage replica locations separately and group requests separately for replica case. AP is involved as it is. I'd think that read replica management would be a cilent of AP rather than threaded through (but as said above, I am not clear what is going on here...) The new Runnables need explanatory comments and better names (?). Should the two types be related? Subclass? Do we need two Callable types? Thanks Sergey. > Failover RPC's for multi-get > - > > Key: HBASE-10356 > URL: https://issues.apache.org/jira/browse/HBASE-10356 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Enis Soztutar >Assignee: Sergey Shelukhin > Fix For: 0.99.0 > > Attachments: HBASE-10356.reference.patch, HBASE-10356.reference.patch > > > This is extension of HBASE-10355 to add failover support for multi-gets. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10477) Regression from HBASE-10337
[ https://issues.apache.org/jira/browse/HBASE-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893734#comment-13893734 ] Hudson commented on HBASE-10477: SUCCESS: Integrated in HBase-TRUNK #4894 (See [https://builds.apache.org/job/HBase-TRUNK/4894/]) HBASE-10477 Regression from HBASE-10337 (nkeywal: rev 1565365) * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java > Regression from HBASE-10337 > --- > > Key: HBASE-10477 > URL: https://issues.apache.org/jira/browse/HBASE-10477 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.99.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon >Priority: Critical > Fix For: 0.98.0, 0.99.0 > > Attachments: 10477.v1.patch > > > a piece of code that should not have make it... > ping [~andrew.purt...@gmail.com] -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10337) HTable.get() uninteruptible
[ https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893733#comment-13893733 ] Hudson commented on HBASE-10337: SUCCESS: Integrated in HBase-TRUNK #4894 (See [https://builds.apache.org/job/HBase-TRUNK/4894/]) HBASE-10477 Regression from HBASE-10337 (nkeywal: rev 1565365) * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java > HTable.get() uninteruptible > --- > > Key: HBASE-10337 > URL: https://issues.apache.org/jira/browse/HBASE-10337 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1 >Reporter: Jonathan Leech >Assignee: Nicolas Liochon > Fix For: 0.98.0, 0.99.0 > > Attachments: 10337-addendum.patch, 10337.v1.patch, 10337.v2.patch > > > I've got a stuck thread on HTable.get() that can't be interrupted, looks like > its designed to be interruptible but can't be in interrupted in practice due > to while loop. > The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line > 981, it catches InterruptedException then goes right back to waiting due to > the while loop. > It looks like future versions of the client (.95+) are significantly > different and might not have this problem... Not sure about release schedules > etc. or if this version is still getting patched. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10478) Hbase book presentations page has broken link
[ https://issues.apache.org/jira/browse/HBASE-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893720#comment-13893720 ] Jonathan Hsieh commented on HBASE-10478: lgtm. Thanks for the fix Vivek and thanks for the review JMS. Will be updated next time we push the docs. > Hbase book presentations page has broken link > - > > Key: HBASE-10478 > URL: https://issues.apache.org/jira/browse/HBASE-10478 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Vivek Ganesan >Assignee: Vivek Ganesan >Priority: Minor > Attachments: HBASE-10478.patch > > > Hbase book page http://hbase.apache.org/book/other.info.pres.html has a link > "Advanced HBase Schema Design". This presentation seems to have been moved > to a new URL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10478) Hbase book presentations page has broken link
[ https://issues.apache.org/jira/browse/HBASE-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-10478: --- Resolution: Fixed Fix Version/s: 0.99.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) > Hbase book presentations page has broken link > - > > Key: HBASE-10478 > URL: https://issues.apache.org/jira/browse/HBASE-10478 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Vivek Ganesan >Assignee: Vivek Ganesan >Priority: Minor > Fix For: 0.99.0 > > Attachments: HBASE-10478.patch > > > Hbase book page http://hbase.apache.org/book/other.info.pres.html has a link > "Advanced HBase Schema Design". This presentation seems to have been moved > to a new URL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10309) Add support to delete empty regions in 0.94.x series
[ https://issues.apache.org/jira/browse/HBASE-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893717#comment-13893717 ] Jonathan Hsieh commented on HBASE-10309: My main concern is doing this safely and in a simple way -- hbck repairs stuff is mostly for after problems occur when we are already messed up. Purposely "breaking" things and then using hbck is just risky. We could outline steps on how to do this but it requires some expertise in case something bad happens. > Add support to delete empty regions in 0.94.x series > > > Key: HBASE-10309 > URL: https://issues.apache.org/jira/browse/HBASE-10309 > Project: HBase > Issue Type: New Feature >Reporter: AcCud > Fix For: 0.94.17 > > > My use case: I have several tables where keys start with a timestamp. Because > of this and combined with the fact that I have set a 15 days retention > period, after a period of time results empty regions. > I am sure that no write will occur in these region. > It would be nice to have a tool to delete regions without being necessary to > stop the cluster. > The easiest way for me is to have a tool that is able to delete all empty > regions, but there wouldn't be any problem to specify which region to delete. > Something like: > deleteRegion -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[ https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-10479: Assignee: (was: Matteo Bertozzi) > HConnection interface is public but is used internally, and contains a bunch > of methods > --- > > Key: HBASE-10479 > URL: https://issues.apache.org/jira/browse/HBASE-10479 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin > > HConnection has too many methods for a public interface, and some of these > should not be public. > It is used extensively for internal purposes, so we keep adding methods to it > that may not make sense for public interface. > The idea is to create a separate internal interface inheriting HConnection, > copy some methods to it and deprecate them on HConnection. New methods for > internal use would be added to new interface; the deprecated methods would > eventually be removed from public interface. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[ https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi reassigned HBASE-10479: --- Assignee: Matteo Bertozzi (was: Sergey Shelukhin) > HConnection interface is public but is used internally, and contains a bunch > of methods > --- > > Key: HBASE-10479 > URL: https://issues.apache.org/jira/browse/HBASE-10479 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Matteo Bertozzi > > HConnection has too many methods for a public interface, and some of these > should not be public. > It is used extensively for internal purposes, so we keep adding methods to it > that may not make sense for public interface. > The idea is to create a separate internal interface inheriting HConnection, > copy some methods to it and deprecate them on HConnection. New methods for > internal use would be added to new interface; the deprecated methods would > eventually be removed from public interface. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
Sergey Shelukhin created HBASE-10479: Summary: HConnection interface is public but is used internally, and contains a bunch of methods Key: HBASE-10479 URL: https://issues.apache.org/jira/browse/HBASE-10479 Project: HBase Issue Type: Improvement Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin HConnection has too many methods for a public interface, and some of there should not be public. It is used extensively for internal purposes, so we keep adding methods to it that may not make sense for public interface. The idea is to create a separate internal interface inheriting HConnection, copy some methods to it and deprecate them on HConnection. New methods for internal use would be added to new interface; the deprecated methods would eventually be removed from public interface. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10479) HConnection interface is public but is used internally, and contains a bunch of methods
[ https://issues.apache.org/jira/browse/HBASE-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-10479: - Description: HConnection has too many methods for a public interface, and some of these should not be public. It is used extensively for internal purposes, so we keep adding methods to it that may not make sense for public interface. The idea is to create a separate internal interface inheriting HConnection, copy some methods to it and deprecate them on HConnection. New methods for internal use would be added to new interface; the deprecated methods would eventually be removed from public interface. was: HConnection has too many methods for a public interface, and some of there should not be public. It is used extensively for internal purposes, so we keep adding methods to it that may not make sense for public interface. The idea is to create a separate internal interface inheriting HConnection, copy some methods to it and deprecate them on HConnection. New methods for internal use would be added to new interface; the deprecated methods would eventually be removed from public interface. > HConnection interface is public but is used internally, and contains a bunch > of methods > --- > > Key: HBASE-10479 > URL: https://issues.apache.org/jira/browse/HBASE-10479 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > > HConnection has too many methods for a public interface, and some of these > should not be public. > It is used extensively for internal purposes, so we keep adding methods to it > that may not make sense for public interface. > The idea is to create a separate internal interface inheriting HConnection, > copy some methods to it and deprecate them on HConnection. New methods for > internal use would be added to new interface; the deprecated methods would > eventually be removed from public interface. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-9218) HBase shell does not allow to change/assign custom table-column families attributes
[
https://issues.apache.org/jira/browse/HBASE-9218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893690#comment-13893690
]
Vasu Mariyala commented on HBASE-9218:
--
[~lhofhansl] Started making the changes. Will upload the patch soon.
> HBase shell does not allow to change/assign custom table-column families
> attributes
> ---
>
> Key: HBASE-9218
> URL: https://issues.apache.org/jira/browse/HBASE-9218
> Project: HBase
> Issue Type: Bug
> Components: shell, Usability
>Affects Versions: 0.94.6.1
>Reporter: Vladimir Rodionov
>Priority: Critical
> Fix For: 0.94.17
>
>
> HBase shell. In 0.94.6.1 the attempt to assign/change custom table or CF
> attribute does not throw any exception but has no affect. The same code works
> fine in Java API (on HTableDescriptor or HColumnDescriptor)
> This is short shell session snippet:
> {code}
> hbase(main):009:0> disable 'T'
> 0 row(s) in 18.0730 seconds
> hbase(main):010:0> alter 'T', NAME => 'df', 'FAKE' => '10'
> Updating all regions with the new schema...
> 5/5 regions updated.
> Done.
> 0 row(s) in 2.2900 seconds
> hbase(main):011:0> enable 'T'
> 0 row(s) in 18.7140 seconds
> hbase(main):012:0> describe 'T'
> DESCRIPTION
> ENABLED
> {NAME => 'T', FAMILIES => [{NAME => 'df', DATA_BLOCK_ENCODING => 'NONE',
> BLOOMFILTER = true
> > 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'GZ',
> MIN_VERSIONS => '0', TTL => '2147483647', K
> EEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'true',
> ENCODE_ON_DISK => 'true', BLOCKCACHE => 'tru
> e'}]}
> {code}
> As you can see, the new attribute 'FAKE' has not been added to column family
> 'cf'.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10478) Hbase book presentations page has broken link
[
https://issues.apache.org/jira/browse/HBASE-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893686#comment-13893686
]
Hadoop QA commented on HBASE-10478:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12627377/HBASE-10478.patch
against trunk revision .
ATTACHMENT ID: 12627377
{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:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color: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/8615//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8615//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8615//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8615//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8615//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8615//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8615//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8615//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8615//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8615//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8615//console
This message is automatically generated.
> Hbase book presentations page has broken link
> -
>
> Key: HBASE-10478
> URL: https://issues.apache.org/jira/browse/HBASE-10478
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Vivek Ganesan
>Assignee: Vivek Ganesan
>Priority: Minor
> Attachments: HBASE-10478.patch
>
>
> Hbase book page http://hbase.apache.org/book/other.info.pres.html has a link
> "Advanced HBase Schema Design". This presentation seems to have been moved
> to a new URL.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10309) Add support to delete empty regions in 0.94.x series
[ https://issues.apache.org/jira/browse/HBASE-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893670#comment-13893670 ] Lars Hofhansl commented on HBASE-10309: --- Can't we reuse the hbck code in a more targeted way for a specific known region that is known ahead of time to be empty (and it won't be written to or split, etc)? I fear that this will come up over and over again with folks that store event data that is access in a most-recent-only way and eventually will be purged; and this is otherwise a compelling usecase for HBase. There are other ways around this (salting, prefix hashing, bounded time windows, etc) but all of those have other drawbacks. > Add support to delete empty regions in 0.94.x series > > > Key: HBASE-10309 > URL: https://issues.apache.org/jira/browse/HBASE-10309 > Project: HBase > Issue Type: New Feature >Reporter: AcCud > Fix For: 0.94.17 > > > My use case: I have several tables where keys start with a timestamp. Because > of this and combined with the fact that I have set a 15 days retention > period, after a period of time results empty regions. > I am sure that no write will occur in these region. > It would be nice to have a tool to delete regions without being necessary to > stop the cluster. > The easiest way for me is to have a tool that is able to delete all empty > regions, but there wouldn't be any problem to specify which region to delete. > Something like: > deleteRegion -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10309) Add support to delete empty regions in 0.94.x series
[ https://issues.apache.org/jira/browse/HBASE-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893641#comment-13893641 ] Jonathan Hsieh commented on HBASE-10309: That could work, but I"m a wary of using hbck for this purpose regularly. The command would be hbck -repairHoles I prefer stack's use merge approach but this isn't available in 0.94. > Add support to delete empty regions in 0.94.x series > > > Key: HBASE-10309 > URL: https://issues.apache.org/jira/browse/HBASE-10309 > Project: HBase > Issue Type: New Feature >Reporter: AcCud > Fix For: 0.94.17 > > > My use case: I have several tables where keys start with a timestamp. Because > of this and combined with the fact that I have set a 15 days retention > period, after a period of time results empty regions. > I am sure that no write will occur in these region. > It would be nice to have a tool to delete regions without being necessary to > stop the cluster. > The easiest way for me is to have a tool that is able to delete all empty > regions, but there wouldn't be any problem to specify which region to delete. > Something like: > deleteRegion -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10475) TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent lease removal
[
https://issues.apache.org/jira/browse/HBASE-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10475:
---
Fix Version/s: 0.98.0
Integrated to 0.98 as well.
> TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent
> lease removal
> -
>
> Key: HBASE-10475
> URL: https://issues.apache.org/jira/browse/HBASE-10475
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Minor
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10475-v1.txt, 10475-v2.txt,
> org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort-output.txt
>
>
> I got the following test failure:
> {code}
> testExceptionFromCoprocessorDuringPut(org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort)
> Time elapsed: 0.049 sec <<< ERROR!
> java.lang.Exception: test timed out after 6 milliseconds
> at java.lang.Object.wait(Native Method)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForNextTaskDone(AsyncProcess.java:837)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForMaximumCurrentTasks(AsyncProcess.java:863)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitUntilDone(AsyncProcess.java:876)
> at
> org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:945)
> at
> org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1225)
> at org.apache.hadoop.hbase.client.HTable.put(HTable.java:887)
> at
> org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort.testExceptionFromCoprocessorDuringPut(TestRegionServerCoprocessorExceptionWithAbort.java:106)
> {code}
> This was due to unexpected LeaseException bringing down region server:
> {code}
> 2014-02-05 19:28:24,752 ERROR [RS_OPEN_REGION-kiyo:56349-1]
> coprocessor.CoprocessorHost(760): The coprocessor
> org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort$BuggyRegionObserver
> threw an unexpected exception
> org.apache.hadoop.hbase.regionserver.LeaseException: lease 'x' does not exist
> at
> org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:221)
> at
> org.apache.hadoop.hbase.regionserver.Leases.cancelLease(Leases.java:206)
> at
> org.apache.hadoop.hbase.coprocessor.SimpleRegionObserver.start(SimpleRegionObserver.java:140)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.startup(CoprocessorHost.java:651)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadInstance(CoprocessorHost.java:261)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10475) TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent lease removal
[
https://issues.apache.org/jira/browse/HBASE-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893618#comment-13893618
]
Andrew Purtell commented on HBASE-10475:
+1 v2 for 0.98
> TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent
> lease removal
> -
>
> Key: HBASE-10475
> URL: https://issues.apache.org/jira/browse/HBASE-10475
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Minor
> Fix For: 0.99.0
>
> Attachments: 10475-v1.txt, 10475-v2.txt,
> org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort-output.txt
>
>
> I got the following test failure:
> {code}
> testExceptionFromCoprocessorDuringPut(org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort)
> Time elapsed: 0.049 sec <<< ERROR!
> java.lang.Exception: test timed out after 6 milliseconds
> at java.lang.Object.wait(Native Method)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForNextTaskDone(AsyncProcess.java:837)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForMaximumCurrentTasks(AsyncProcess.java:863)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitUntilDone(AsyncProcess.java:876)
> at
> org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:945)
> at
> org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1225)
> at org.apache.hadoop.hbase.client.HTable.put(HTable.java:887)
> at
> org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort.testExceptionFromCoprocessorDuringPut(TestRegionServerCoprocessorExceptionWithAbort.java:106)
> {code}
> This was due to unexpected LeaseException bringing down region server:
> {code}
> 2014-02-05 19:28:24,752 ERROR [RS_OPEN_REGION-kiyo:56349-1]
> coprocessor.CoprocessorHost(760): The coprocessor
> org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort$BuggyRegionObserver
> threw an unexpected exception
> org.apache.hadoop.hbase.regionserver.LeaseException: lease 'x' does not exist
> at
> org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:221)
> at
> org.apache.hadoop.hbase.regionserver.Leases.cancelLease(Leases.java:206)
> at
> org.apache.hadoop.hbase.coprocessor.SimpleRegionObserver.start(SimpleRegionObserver.java:140)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.startup(CoprocessorHost.java:651)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadInstance(CoprocessorHost.java:261)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10478) Hbase book presentations page has broken link
[ https://issues.apache.org/jira/browse/HBASE-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893610#comment-13893610 ] Jean-Marc Spaggiari commented on HBASE-10478: - SGTM +1 > Hbase book presentations page has broken link > - > > Key: HBASE-10478 > URL: https://issues.apache.org/jira/browse/HBASE-10478 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Vivek Ganesan >Assignee: Vivek Ganesan >Priority: Minor > Attachments: HBASE-10478.patch > > > Hbase book page http://hbase.apache.org/book/other.info.pres.html has a link > "Advanced HBase Schema Design". This presentation seems to have been moved > to a new URL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10185) HBaseClient retries even though a DoNotRetryException was thrown
[
https://issues.apache.org/jira/browse/HBASE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893601#comment-13893601
]
Lars Hofhansl commented on HBASE-10185:
---
Change looks good. And I think this part is a problem in 0.94 as well. I think
James observed that one as well somewhere.
> HBaseClient retries even though a DoNotRetryException was thrown
>
>
> Key: HBASE-10185
> URL: https://issues.apache.org/jira/browse/HBASE-10185
> Project: HBase
> Issue Type: Bug
> Components: IPC/RPC
>Affects Versions: 0.94.12, 0.99.0
>Reporter: Samarth
> Fix For: 0.99.0
>
> Attachments: 10185.v1.patch
>
>
> Throwing a DoNotRetryIOException inside Writable.write(Dataoutput) method
> doesn't prevent HBase from retrying. Debugging the code locally, I figured
> that the bug lies in the way HBaseClient simply throws an IOException when it
> sees that a connection has been closed unexpectedly.
> Method:
> public Writable call(Writable param, InetSocketAddress addr,
>Class protocol,
>User ticket, int rpcTimeout)
> Excerpt of code where the bug is present:
> while (!call.done) {
> if (connection.shouldCloseConnection.get()) {
> throw new IOException("Unexpected closed connection");
> }
> Throwing this IOException causes the ServerCallable.translateException(t) to
> be a no-op resulting in HBase retrying.
> From my limited view and understanding of the code, one way I could think of
> handling this is by looking at the closeConnection member variable of a
> connection to determine what kind of exception should be thrown.
> Specifically, when a connection is closed, the current code does this:
> protected synchronized void markClosed(IOException e) {
> if (shouldCloseConnection.compareAndSet(false, true)) {
> closeException = e;
> notifyAll();
> }
> }
> Within HBaseClient's call method, the code could possibly be modified to:
> while (!call.done) {
> if (connection.shouldCloseConnection.get() ) {
> if(connection.closeException instanceof
> DoNotRetryIOException) {
> throw closeException;
> }
> throw new IOException("Unexpected closed connection");
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10356) Failover RPC's for multi-get
[ https://issues.apache.org/jira/browse/HBASE-10356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893583#comment-13893583 ] Sergey Shelukhin commented on HBASE-10356: -- bq. Why does Action have to know about replicaid? Currently it is the outline of a Get, Put, or Delete just for keeping up an index so we can run multi of these in a request... and make sense of the result and exceptoins when they come back. replicaid stuff should be going on elsewhere where we are figuring the destination server for this Action? Won't you want to be able to take an Action that fails one replica and point it at another replica (w/o having to update the replica it is carrying?) Action represents local context for a particular... action (which is different from Action, hence action.getAction(), poor naming imho) that is a part of MultiAction. Local context included original index, now it also includes replica ID for the same reason, it needs to be propagated between sending request and processing response (not going to server, though). Seems like a logical place to put it. bq. On AsyncProcess knowing about replicas, again, shouldn't it be a read replica driver class that runs the AsyncProcess making sense of results and rescheduling against new replicas if failure rather than doctoring of AsyncProcess? First, replica calls run in parallel with normal calls, it's not just for failures, so there has to be a point of syncronization. Second, AP currently already manages finding the locations and grouping of request, it wouldn't make sense to have another external place to manage replica locations separately and group requests separately for replica case. If you notice, the send code is almost the same replicas or no replicas, the only difference is how we group, and the scheduling of replica calls themselves. bq. Its hard to figure how this works. Is there a bit of doc on it somewhere? I will augment the comments :) bq. A AsyncRequestFutureImpl has a ReplicaRunnable. What is a ReplicaRunnable? bq. SingleServerRunnable is what happens when no read replicas? Why ain't SingleServerRunnable an instance of ReplicaRunnable only replicas==1? Both are just thread runnables; the second is just moved code - previously it was an inline runnable for calls, I moved it to make code cleaner. The first is a runnable for replica calls thread. Replica calls could be made on the same thread, but that would compromise the async behavior because we wait before making them. > Failover RPC's for multi-get > - > > Key: HBASE-10356 > URL: https://issues.apache.org/jira/browse/HBASE-10356 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Enis Soztutar >Assignee: Sergey Shelukhin > Fix For: 0.99.0 > > Attachments: HBASE-10356.reference.patch, HBASE-10356.reference.patch > > > This is extension of HBASE-10355 to add failover support for multi-gets. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10478) Hbase book presentations page has broken link
[ https://issues.apache.org/jira/browse/HBASE-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893578#comment-13893578 ] Vivek Ganesan commented on HBASE-10478: --- Uploaded a patch pointing the link to correct URL > Hbase book presentations page has broken link > - > > Key: HBASE-10478 > URL: https://issues.apache.org/jira/browse/HBASE-10478 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Vivek Ganesan >Assignee: Vivek Ganesan >Priority: Minor > Attachments: HBASE-10478.patch > > > Hbase book page http://hbase.apache.org/book/other.info.pres.html has a link > "Advanced HBase Schema Design". This presentation seems to have been moved > to a new URL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10477) Regression from HBASE-10337
[ https://issues.apache.org/jira/browse/HBASE-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893570#comment-13893570 ] Andrew Purtell commented on HBASE-10477: Yes this made it. I will redo the tag again and build again later today. > Regression from HBASE-10337 > --- > > Key: HBASE-10477 > URL: https://issues.apache.org/jira/browse/HBASE-10477 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.99.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon >Priority: Critical > Fix For: 0.98.0, 0.99.0 > > Attachments: 10477.v1.patch > > > a piece of code that should not have make it... > ping [~andrew.purt...@gmail.com] -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10185) HBaseClient retries even though a DoNotRetryException was thrown
[
https://issues.apache.org/jira/browse/HBASE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893571#comment-13893571
]
Hadoop QA commented on HBASE-10185:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12627355/10185.v1.patch
against trunk revision .
ATTACHMENT ID: 12627355
{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:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color: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/8614//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8614//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8614//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8614//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8614//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8614//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8614//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8614//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8614//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8614//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8614//console
This message is automatically generated.
> HBaseClient retries even though a DoNotRetryException was thrown
>
>
> Key: HBASE-10185
> URL: https://issues.apache.org/jira/browse/HBASE-10185
> Project: HBase
> Issue Type: Bug
> Components: IPC/RPC
>Affects Versions: 0.94.12, 0.99.0
>Reporter: Samarth
> Fix For: 0.99.0
>
> Attachments: 10185.v1.patch
>
>
> Throwing a DoNotRetryIOException inside Writable.write(Dataoutput) method
> doesn't prevent HBase from retrying. Debugging the code locally, I figured
> that the bug lies in the way HBaseClient simply throws an IOException when it
> sees that a connection has been closed unexpectedly.
> Method:
> public Writable call(Writable param, InetSocketAddress addr,
>Class protocol,
>User ticket, int rpcTimeout)
> Excerpt of code where the bug is present:
> while (!call.done) {
> if (connection.shouldCloseConnection.get()) {
> throw new IOException("Unexpected closed connection");
> }
> Throwing this IOException causes the ServerCallable.translateException(t) to
> be a no-op resulting in HBase retrying.
> From my limited view and understanding of the code, one way I could think of
> handling this is by looking at the closeConnection member variable of a
> connection to determine what kind of exception should be thrown.
> Specifically, when a connection is closed, the current code does this:
> protected synchronized void markClosed(IOException e) {
> if (shouldCloseConnection.compareAndSet(false, true)) {
> closeException = e;
>
[jira] [Updated] (HBASE-10478) Hbase book presentations page has broken link
[ https://issues.apache.org/jira/browse/HBASE-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vivek Ganesan updated HBASE-10478: -- Status: Patch Available (was: Open) > Hbase book presentations page has broken link > - > > Key: HBASE-10478 > URL: https://issues.apache.org/jira/browse/HBASE-10478 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Vivek Ganesan >Assignee: Vivek Ganesan >Priority: Minor > Attachments: HBASE-10478.patch > > > Hbase book page http://hbase.apache.org/book/other.info.pres.html has a link > "Advanced HBase Schema Design". This presentation seems to have been moved > to a new URL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10478) Hbase book presentations page has broken link
[ https://issues.apache.org/jira/browse/HBASE-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vivek Ganesan updated HBASE-10478: -- Attachment: HBASE-10478.patch > Hbase book presentations page has broken link > - > > Key: HBASE-10478 > URL: https://issues.apache.org/jira/browse/HBASE-10478 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Vivek Ganesan >Assignee: Vivek Ganesan >Priority: Minor > Attachments: HBASE-10478.patch > > > Hbase book page http://hbase.apache.org/book/other.info.pres.html has a link > "Advanced HBase Schema Design". This presentation seems to have been moved > to a new URL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
