[jira] [Commented] (HBASE-6089) SSH and AM.joinCluster causes Concurrent Modification exception.
[ https://issues.apache.org/jira/browse/HBASE-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13284973#comment-13284973 ] stack commented on HBASE-6089: -- Patch looks good to me. Rather than synchronize, why not use a concurrentskiplistmap? Also, for sure we have synchronized all accesses to this.region. What about its tie to this.servers. That is still respected by this patch? SSH and AM.joinCluster causes Concurrent Modification exception. Key: HBASE-6089 URL: https://issues.apache.org/jira/browse/HBASE-6089 Project: HBase Issue Type: Bug Affects Versions: 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: rajeshbabu Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-6089_92.patch, HBASE-6089_94.patch, HBASE-6089_trunk.patch AM.regions map is parallely accessed in SSH and Master initialization leading to ConcurrentModificationException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5955) Guava 11 drops MapEvictionListener and Hadoop 2.0.0-alpha requires it
[
https://issues.apache.org/jira/browse/HBASE-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13284974#comment-13284974
]
stack commented on HBASE-5955:
--
We want to do same for 0.94? Does version of hadoop even matter for this issue?
Up on dev list, discussion had it that only 0.96 can require 1.0.0 hadoop as
its minimum version.
Guava 11 drops MapEvictionListener and Hadoop 2.0.0-alpha requires it
-
Key: HBASE-5955
URL: https://issues.apache.org/jira/browse/HBASE-5955
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Andrew Purtell
Assignee: Lars Hofhansl
Fix For: 0.94.1
Hadoop 2.0.0-alpha depends on Guava 11.0.2. Updating HBase dependencies to
match produces the following compilation errors:
{code}
[ERROR] SingleSizeCache.java:[41,32] cannot find symbol
[ERROR] symbol : class MapEvictionListener
[ERROR] location: package com.google.common.collect
[ERROR]
[ERROR] SingleSizeCache.java:[94,4] cannot find symbol
[ERROR] symbol : class MapEvictionListener
[ERROR] location: class org.apache.hadoop.hbase.io.hfile.slab.SingleSizeCache
[ERROR]
[ERROR] SingleSizeCache.java:[94,69] cannot find symbol
[ERROR] symbol : class MapEvictionListener
[ERROR] location: class org.apache.hadoop.hbase.io.hfile.slab.SingleSizeCache
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6097) TestHRegion.testBatchPut is flaky on 0.92
[ https://issues.apache.org/jira/browse/HBASE-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6097: - Resolution: Fixed Fix Version/s: 0.92.2 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) +1 on minimal fix for an old branch rather than pull in a bunch of new code. Thanks for the patch Gregory. TestHRegion.testBatchPut is flaky on 0.92 - Key: HBASE-6097 URL: https://issues.apache.org/jira/browse/HBASE-6097 Project: HBase Issue Type: Bug Components: test, wal Affects Versions: 0.92.1 Reporter: Gregory Chanan Assignee: Gregory Chanan Fix For: 0.92.2 Attachments: HBASE-6097.patch If I run this test in a loop, I get failures like the following: Error Message: expected:1 but was:2 Stack Trace: junit.framework.AssertionFailedError: expected:1 but was:2 at junit.framework.Assert.fail(Assert.java:50) at junit.framework.Assert.failNotEquals(Assert.java:287) at junit.framework.Assert.assertEquals(Assert.java:67) at junit.framework.Assert.assertEquals(Assert.java:134) at junit.framework.Assert.assertEquals(Assert.java:140) at org.apache.hadoop.hbase.regionserver.TestHRegion.testBatchPut(TestHRegion.java:536) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6114) CacheControl flags should be tunable per table schema per CF
[ https://issues.apache.org/jira/browse/HBASE-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285030#comment-13285030 ] stack commented on HBASE-6114: -- +1 on patch Change shouldCacheDataOnWrite to isCacheDataOnWrite on commit and same for all other should methods. CacheControl flags should be tunable per table schema per CF Key: HBASE-6114 URL: https://issues.apache.org/jira/browse/HBASE-6114 Project: HBase Issue Type: Improvement Affects Versions: 0.92.2, 0.96.0, 0.94.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Attachments: 6114-0.92.patch, 6114-0.94.patch, 6114-trunk.patch CacheControl flags should be tunable per table schema per CF, especially cacheDataOnWrite, also cacheIndexesOnWrite and cacheBloomsOnWrite. It looks like Store uses CacheConfig(Configuration conf, HColumnDescriptor family) to construct the CacheConfig, so it's a simple change there to override configuration properties with values of table schema attributes if present. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6114) CacheControl flags should be tunable per table schema per CF
[ https://issues.apache.org/jira/browse/HBASE-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285076#comment-13285076 ] stack commented on HBASE-6114: -- Just going by javabean convention for methods that return boolean E.g. http://docstore.mik.ua/orelly/java-ent/jnut/ch06_02.htm CacheControl flags should be tunable per table schema per CF Key: HBASE-6114 URL: https://issues.apache.org/jira/browse/HBASE-6114 Project: HBase Issue Type: Improvement Affects Versions: 0.92.2, 0.96.0, 0.94.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Attachments: 6114-0.92.patch, 6114-0.94.patch, 6114-trunk.patch CacheControl flags should be tunable per table schema per CF, especially cacheDataOnWrite, also cacheIndexesOnWrite and cacheBloomsOnWrite. It looks like Store uses CacheConfig(Configuration conf, HColumnDescriptor family) to construct the CacheConfig, so it's a simple change there to override configuration properties with values of table schema attributes if present. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-6126) Fix broke TestLocalHBaseCluster in 0.92/0.94
stack created HBASE-6126: Summary: Fix broke TestLocalHBaseCluster in 0.92/0.94 Key: HBASE-6126 URL: https://issues.apache.org/jira/browse/HBASE-6126 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Related to HBASE-6100 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6126) Fix broke TestLocalHBaseCluster in 0.92/0.94
[ https://issues.apache.org/jira/browse/HBASE-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6126: - Attachment: fixTestLocalHBaseCluster.txt One line fix took care of it failing locally for me. Going to commit. Fix broke TestLocalHBaseCluster in 0.92/0.94 Key: HBASE-6126 URL: https://issues.apache.org/jira/browse/HBASE-6126 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Attachments: fixTestLocalHBaseCluster.txt Related to HBASE-6100 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-6126) Fix broke TestLocalHBaseCluster in 0.92/0.94
[ https://issues.apache.org/jira/browse/HBASE-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-6126. -- Resolution: Fixed Fix Version/s: 0.94.1 0.92.2 Applied to 0.92 and 0.94 branches. TRUNK already had this change. Fix broke TestLocalHBaseCluster in 0.92/0.94 Key: HBASE-6126 URL: https://issues.apache.org/jira/browse/HBASE-6126 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Fix For: 0.92.2, 0.94.1 Attachments: fixTestLocalHBaseCluster.txt Related to HBASE-6100 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[
https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285125#comment-13285125
]
stack commented on HBASE-4720:
--
@Mubarak Do you like Jimmy's changes?
Jimmy, should you do a define for 'put'? Should the compare lowercase first?
Jimmy, there is no excuse for dup'ing code:
{code}
+if (put.equals(check)) {
+ return checkAndPut(model);
+} else if (delete.equals(check)) {
+ return checkAndDelete(model);
+} else {
+ if (check != null check.length() 0) {
+LOG.warn(Unknown check value: + check + , ignored);
+ }
+ return update(model, false);
+}
{code}
Else looks good to me Jimmy
Implement atomic update operations (checkAndPut, checkAndDelete) for REST
client/server
Key: HBASE-4720
URL: https://issues.apache.org/jira/browse/HBASE-4720
Project: HBase
Issue Type: Improvement
Reporter: Daniel Lord
Assignee: Mubarak Seyed
Fix For: 0.96.0
Attachments: 4720_trunk.patch, HBASE-4720.trunk.v1.patch,
HBASE-4720.trunk.v2.patch, HBASE-4720.trunk.v3.patch,
HBASE-4720.trunk.v4.patch, HBASE-4720.trunk.v5.patch,
HBASE-4720.trunk.v6.patch, HBASE-4720.trunk.v7.patch, HBASE-4720.v1.patch,
HBASE-4720.v3.patch
I have several large application/HBase clusters where an application node
will occasionally need to talk to HBase from a different cluster. In order
to help ensure some of my consistency guarantees I have a sentinel table that
is updated atomically as users interact with the system. This works quite
well for the regular hbase client but the REST client does not implement
the checkAndPut and checkAndDelete operations. This exposes the application
to some race conditions that have to be worked around. It would be ideal if
the same checkAndPut/checkAndDelete operations could be supported by the REST
client.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5959) Add other load balancers
[ https://issues.apache.org/jira/browse/HBASE-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285170#comment-13285170 ] stack commented on HBASE-5959: -- Why does RegionPlanComparator implemenent Serializable? Maybe doc why you are doing this compare on regionid... are you dependent on it being timestamp? Why not do 'return r.getRegionInfo().getRegionId() - l.getRegionInfo().getRegionId();' rather than check 0 and return -1, etc? Remove a 'the' from ...It provides the the functions used to by... Should RegionPlanComparator be public? Could it be package private? It needs to be public so the balancer package has access? Shouldn't setMasterServices instead be passed to the constructor? Otherwise, could have an instance of a balancer that was not viable, not until after setMasterServices was called (ditto w/ setClusterStatus)? So the method roundRobinAssignment is in the base load balancer. Its expected by all load balancer implementations? Its behavior will be same for all? Fix 'randmo server.' Does ClusterLoadState need to be public? Does it need audience annotation? Why a RegionInfoComparator class and then also a comparator in RegionInfo class? Is the latter a mistaken inclusion? Comment seems wrong '+ // The cache for where load balancers are located.' This is an expensive call? computeHDFSBlocksDistribution? Goes to NN? We do it for every region in cluster every time we balance? We doing to DOS the NN? The call to getTableDescriptor should be getting a descriptor from cache of table descriptors maintained by the master, right? Why ServerAndLoad implement Serializable? You planning on java serializing it? Does StochasticLoadBalancer have to be a public class? This stuff looks great. Nice tests. Add other load balancers Key: HBASE-5959 URL: https://issues.apache.org/jira/browse/HBASE-5959 Project: HBase Issue Type: New Feature Components: master Affects Versions: 0.96.0 Reporter: Elliott Clark Assignee: Elliott Clark Attachments: HBASE-5959-0.patch, HBASE-5959-1.patch, HBASE-5959-11.patch, HBASE-5959-2.patch, HBASE-5959-3.patch, HBASE-5959-6.patch, HBASE-5959-7.patch, HBASE-5959-8.patch, HBASE-5959-9.patch, HBASE-5959.D3189.1.patch, HBASE-5959.D3189.2.patch, HBASE-5959.D3189.3.patch, HBASE-5959.D3189.4.patch, HBASE-5959.D3189.5.patch, HBASE-5959.D3189.6.patch, HBASE-5959.D3189.7.patch Now that balancers are pluggable we should give some options.b -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6084) Server Load does not display correctly on the ui
[ https://issues.apache.org/jira/browse/HBASE-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6084: - Resolution: Fixed Fix Version/s: 0.96.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to trunk (I had to do some messing to get the new test class in TestServerLoad moving it under hbase-server). Thanks Elliott Server Load does not display correctly on the ui Key: HBASE-6084 URL: https://issues.apache.org/jira/browse/HBASE-6084 Project: HBase Issue Type: Bug Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 0.96.0 Attachments: HBASE-6084-0.patch, HBASE-6084-1.patch, HBASE-6084-2.patch, HBASE-6084-3.patch The ui uses the toString method and toString does not implement it any more. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285183#comment-13285183 ] stack commented on HBASE-4720: -- +1 on patch. Tests look good. Does it work for you Jimmy? Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.96.0 Attachments: 4720_trunk.patch, 4720_trunk_v2.patch, HBASE-4720.trunk.v1.patch, HBASE-4720.trunk.v2.patch, HBASE-4720.trunk.v3.patch, HBASE-4720.trunk.v4.patch, HBASE-4720.trunk.v5.patch, HBASE-4720.trunk.v6.patch, HBASE-4720.trunk.v7.patch, HBASE-4720.v1.patch, HBASE-4720.v3.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-5948) Deprecate and remove the Avro gateway
[ https://issues.apache.org/jira/browse/HBASE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5948. -- Resolution: Fixed Fix Version/s: 0.96.0 Hadoop Flags: Reviewed Committed to trunk. Thanks for the patch Elliott Deprecate and remove the Avro gateway - Key: HBASE-5948 URL: https://issues.apache.org/jira/browse/HBASE-5948 Project: HBase Issue Type: Task Affects Versions: 0.96.0 Reporter: Andrew Purtell Assignee: Elliott Clark Priority: Blocker Fix For: 0.96.0 Attachments: HBASE-5948-0.patch, HBASE-5948-1.patch Deprecate the Avro gateway in 0.94. Remove in 0.96. Made a blocker against that release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6043) Add Increment Coalescing in thrift.
[ https://issues.apache.org/jira/browse/HBASE-6043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6043: - Resolution: Fixed Fix Version/s: 0.96.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to trunk. Thanks Elliott. (This patch has been running at SU for ~ a year now) Add Increment Coalescing in thrift. --- Key: HBASE-6043 URL: https://issues.apache.org/jira/browse/HBASE-6043 Project: HBase Issue Type: Improvement Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 0.96.0 Attachments: HBASE-6043-0.patch, HBASE-6043-1.patch, HBASE-6043-10.patch, HBASE-6043-2.patch, HBASE-6043-3.patch, HBASE-6043-4.patch, HBASE-6043-5.patch, HBASE-6043-6.patch, HBASE-6043-7.patch, HBASE-6043-8.patch, HBASE-6043-9.patch Since the thrift server uses the client api reducing the number of rpc's greatly speeds up increments. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6114) CacheControl flags should be tunable per table schema per CF
[ https://issues.apache.org/jira/browse/HBASE-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285208#comment-13285208 ] stack commented on HBASE-6114: -- bq. What about existing methods like CacheConfig#shouldCacheDataOnRead and CacheConfig#shouldCacheBlockOnRead? Change those too? Ugh. Who let those in! Maybe just commit what you have then Andrew if it is keeping the pattern set elsewhere in this class? CacheControl flags should be tunable per table schema per CF Key: HBASE-6114 URL: https://issues.apache.org/jira/browse/HBASE-6114 Project: HBase Issue Type: Improvement Affects Versions: 0.92.2, 0.96.0, 0.94.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Attachments: 6114-0.92.patch, 6114-0.94.patch, 6114-trunk.patch CacheControl flags should be tunable per table schema per CF, especially cacheDataOnWrite, also cacheIndexesOnWrite and cacheBloomsOnWrite. It looks like Store uses CacheConfig(Configuration conf, HColumnDescriptor family) to construct the CacheConfig, so it's a simple change there to override configuration properties with values of table schema attributes if present. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6113) [eclipse] Fix eclipse import of hbase-assembly null pointer
[ https://issues.apache.org/jira/browse/HBASE-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285215#comment-13285215 ] stack commented on HBASE-6113: -- bq. Simple fix - apparently you always need to include the lifecycle-mapping plugin version, even if its defined in the parent. For eclipse? [eclipse] Fix eclipse import of hbase-assembly null pointer --- Key: HBASE-6113 URL: https://issues.apache.org/jira/browse/HBASE-6113 Project: HBase Issue Type: Bug Reporter: Jesse Yates Assignee: Jesse Yates Fix For: 0.96.0 Attachments: hbase-6113.patch occasionally, eclipse will throw a null pointer when attempting to import all the modules via m2eclipse. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6113) [eclipse] Fix eclipse import of hbase-assembly null pointer
[ https://issues.apache.org/jira/browse/HBASE-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6113: - Resolution: Fixed Fix Version/s: 0.96.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Applied to trunk. Thanks for the patch Jesse. [eclipse] Fix eclipse import of hbase-assembly null pointer --- Key: HBASE-6113 URL: https://issues.apache.org/jira/browse/HBASE-6113 Project: HBase Issue Type: Bug Reporter: Jesse Yates Assignee: Jesse Yates Fix For: 0.96.0 Attachments: hbase-6113.patch occasionally, eclipse will throw a null pointer when attempting to import all the modules via m2eclipse. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5959) Add other load balancers
[ https://issues.apache.org/jira/browse/HBASE-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285219#comment-13285219 ] stack commented on HBASE-5959: -- I'm +1 on this patch. Ted? Add other load balancers Key: HBASE-5959 URL: https://issues.apache.org/jira/browse/HBASE-5959 Project: HBase Issue Type: New Feature Components: master Affects Versions: 0.96.0 Reporter: Elliott Clark Assignee: Elliott Clark Attachments: HBASE-5959-0.patch, HBASE-5959-1.patch, HBASE-5959-11.patch, HBASE-5959-12.patch, HBASE-5959-2.patch, HBASE-5959-3.patch, HBASE-5959-6.patch, HBASE-5959-7.patch, HBASE-5959-8.patch, HBASE-5959-9.patch, HBASE-5959.D3189.1.patch, HBASE-5959.D3189.2.patch, HBASE-5959.D3189.3.patch, HBASE-5959.D3189.4.patch, HBASE-5959.D3189.5.patch, HBASE-5959.D3189.6.patch, HBASE-5959.D3189.7.patch Now that balancers are pluggable we should give some options.b -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6074) TestHLog is flaky
[ https://issues.apache.org/jira/browse/HBASE-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285221#comment-13285221 ] stack commented on HBASE-6074: -- @Deveraj What does your patch do? Does it just move the test? TestHLog is flaky - Key: HBASE-6074 URL: https://issues.apache.org/jira/browse/HBASE-6074 Project: HBase Issue Type: Test Components: test Affects Versions: 0.92.0 Reporter: Devaraj Das Attachments: 6074-1.patch When I run TestHLog in a loop, I see failures. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6049) Serializing List containing null elements will cause NullPointerException in HbaseObjectWritable.writeObject()
[ https://issues.apache.org/jira/browse/HBASE-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285227#comment-13285227 ] stack commented on HBASE-6049: -- @MaryAnn Does org.apache.hadoop.hbase.io.TestHbaseObjectWritable fail for you locally w/ this patch in place? Thanks. Serializing List containing null elements will cause NullPointerException in HbaseObjectWritable.writeObject() Key: HBASE-6049 URL: https://issues.apache.org/jira/browse/HBASE-6049 Project: HBase Issue Type: Bug Components: io Affects Versions: 0.94.0 Reporter: Maryann Xue Attachments: HBASE-6049-v2.patch, HBASE-6049.patch An error case could be in Coprocessor AggregationClient, the median() function handles an empty region and returns a List Object with the first element as a Null value. NPE occurs in the RPC response stage and the response never gets sent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6109) Improve RIT performances during assignment on large clusters
[ https://issues.apache.org/jira/browse/HBASE-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285229#comment-13285229 ] stack commented on HBASE-6109: -- bq. Renamed to LockerByString. If you have a better name... regionLocker? Improve RIT performances during assignment on large clusters Key: HBASE-6109 URL: https://issues.apache.org/jira/browse/HBASE-6109 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.96.0 Reporter: nkeywal Assignee: nkeywal Priority: Minor Attachments: 6109.v7.patch The main points in this patch are: - lowering the number of copy of the RIT list - lowering the number of synchronization - synchronizing on a region rather than on everything It also contains: - some fixes around the RIT notification: the list was sometimes modified without a corresponding 'notify'. - some tests flakiness correction, actually unrelated to this patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6043) Add Increment Coalescing in thrift.
[ https://issues.apache.org/jira/browse/HBASE-6043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285245#comment-13285245 ] stack commented on HBASE-6043: -- The patch added new files to src instead of to hbase-server/src. I just fixed this. Add Increment Coalescing in thrift. --- Key: HBASE-6043 URL: https://issues.apache.org/jira/browse/HBASE-6043 Project: HBase Issue Type: Improvement Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 0.96.0 Attachments: HBASE-6043-0.patch, HBASE-6043-1.patch, HBASE-6043-10.patch, HBASE-6043-2.patch, HBASE-6043-3.patch, HBASE-6043-4.patch, HBASE-6043-5.patch, HBASE-6043-6.patch, HBASE-6043-7.patch, HBASE-6043-8.patch, HBASE-6043-9.patch Since the thrift server uses the client api reducing the number of rpc's greatly speeds up increments. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6107) Distributed log splitting hangs even there is no task under /hbase/splitlog
[ https://issues.apache.org/jira/browse/HBASE-6107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6107: - Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to trunk. Test failures seem unrelated. Jimmy should this go into 0.94/0.92? Distributed log splitting hangs even there is no task under /hbase/splitlog --- Key: HBASE-6107 URL: https://issues.apache.org/jira/browse/HBASE-6107 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.96.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.96.0 Attachments: 6107_v3-new.patch, hbase-6107.patch, hbase-6107_v3-new.patch, hbase_6107_v2.patch, hbase_6107_v3.patch Sometimes, master web UI shows the distributed log splitting is going on, waiting for one last task to be done. However, in ZK, there is no task under /hbase/splitlog at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5533) Add more metrics to HBase
[ https://issues.apache.org/jira/browse/HBASE-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285262#comment-13285262 ] stack commented on HBASE-5533: -- @Ted Thanks for noticing. I made a blocker over on HBASE-6131 to fix. Add more metrics to HBase - Key: HBASE-5533 URL: https://issues.apache.org/jira/browse/HBASE-5533 Project: HBase Issue Type: Improvement Affects Versions: 0.92.2, 0.94.0 Reporter: Shaneal Manek Assignee: Shaneal Manek Priority: Minor Fix For: 0.92.2, 0.94.0, 0.96.0 Attachments: BlockingQueueContention.java, HBASE-5533-0.92-v4.patch, HBASE-5533-TRUNK-v6.patch, HBASE-5533-TRUNK-v6.patch, HBASE-5533-v7-0.92.patch, TimingOverhead.java, hbase-5533-0.92.patch, hbase5533-0.92-v2.patch, hbase5533-0.92-v3.patch, hbase5533-0.92-v5.patch, histogram_web_ui.png To debug/monitor production clusters, there are some more metrics I wish I had available. In particular: - Although the average FS latencies are useful, a 'histogram' of recent latencies (90% of reads completed in under 100ms, 99% in under 200ms, etc) would be more useful - Similar histograms of latencies on common operations (GET, PUT, DELETE) would be useful - Counting the number of accesses to each region to detect hotspotting - Exposing the current number of HLog files -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-6131) Add attribution for code added by HBASE-5533 metrics
stack created HBASE-6131: Summary: Add attribution for code added by HBASE-5533 metrics Key: HBASE-6131 URL: https://issues.apache.org/jira/browse/HBASE-6131 Project: HBase Issue Type: Task Reporter: stack Priority: Blocker See the comment over in https://issues.apache.org/jira/browse/HBASE-5533?focusedCommentId=13283920page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13283920 The metrics histogram code was copied w/o attribution. Fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6131) Add attribution for code added by HBASE-5533 metrics
[ https://issues.apache.org/jira/browse/HBASE-6131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285275#comment-13285275 ] stack commented on HBASE-6131: -- That sounds better @Jeff. It looks to be up in maven: http://mvnrepository.com/artifact/com.yammer.metrics/metrics-core Add attribution for code added by HBASE-5533 metrics Key: HBASE-6131 URL: https://issues.apache.org/jira/browse/HBASE-6131 Project: HBase Issue Type: Task Reporter: stack Priority: Blocker See the comment over in https://issues.apache.org/jira/browse/HBASE-5533?focusedCommentId=13283920page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13283920 The metrics histogram code was copied w/o attribution. Fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6107) Distributed log splitting hangs even there is no task under /hbase/splitlog
[ https://issues.apache.org/jira/browse/HBASE-6107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6107: - Attachment: 6107_v3_094-new.patch Here is what I applied to 0.94 and 0.92. Same as to trunk but path to files adjusted to remove hbase-server prefix Distributed log splitting hangs even there is no task under /hbase/splitlog --- Key: HBASE-6107 URL: https://issues.apache.org/jira/browse/HBASE-6107 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.96.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.96.0 Attachments: 6107_v3-new.patch, 6107_v3_094-new.patch, hbase-6107.patch, hbase-6107_v3-new.patch, hbase_6107_v2.patch, hbase_6107_v3.patch Sometimes, master web UI shows the distributed log splitting is going on, waiting for one last task to be done. However, in ZK, there is no task under /hbase/splitlog at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4655) Document architecture of backups
[ https://issues.apache.org/jira/browse/HBASE-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285289#comment-13285289 ] stack commented on HBASE-4655: -- What should we do w/ this doc Karthik? Seems like still stuff to build out? Should we make issues for whats to be done? Document architecture of backups Key: HBASE-4655 URL: https://issues.apache.org/jira/browse/HBASE-4655 Project: HBase Issue Type: Sub-task Components: documentation, regionserver Reporter: Karthik Ranganathan Assignee: Karthik Ranganathan Attachments: HBase Backups Architecture v2.docx, HBase Backups Architecture.docx Basic idea behind the backup architecture for HBase -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6043) Add Increment Coalescing in thrift.
[ https://issues.apache.org/jira/browse/HBASE-6043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285360#comment-13285360 ] stack commented on HBASE-6043: -- I applied the addendum to trunk. Thanks Elliott. Add Increment Coalescing in thrift. --- Key: HBASE-6043 URL: https://issues.apache.org/jira/browse/HBASE-6043 Project: HBase Issue Type: Improvement Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 0.96.0 Attachments: HBASE-6043-0.patch, HBASE-6043-1.patch, HBASE-6043-10.patch, HBASE-6043-2.patch, HBASE-6043-3.patch, HBASE-6043-4.patch, HBASE-6043-5.patch, HBASE-6043-6.patch, HBASE-6043-7.patch, HBASE-6043-8.patch, HBASE-6043-9.patch, HBASE-6043-ADD.patch Since the thrift server uses the client api reducing the number of rpc's greatly speeds up increments. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6083) Modify old filter tests to use Junit4/no longer use HBaseTestCase
[ https://issues.apache.org/jira/browse/HBASE-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6083: - Attachment: 6083v2.txt Make Juhani's patch apply to trunk (trunk was mvn modularized since patch was made) Modify old filter tests to use Junit4/no longer use HBaseTestCase - Key: HBASE-6083 URL: https://issues.apache.org/jira/browse/HBASE-6083 Project: HBase Issue Type: Improvement Reporter: Juhani Connolly Priority: Minor Attachments: 6083v2.txt, hbase-6083.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6083) Modify old filter tests to use Junit4/no longer use HBaseTestCase
[ https://issues.apache.org/jira/browse/HBASE-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6083: - Status: Open (was: Patch Available) Modify old filter tests to use Junit4/no longer use HBaseTestCase - Key: HBASE-6083 URL: https://issues.apache.org/jira/browse/HBASE-6083 Project: HBase Issue Type: Improvement Reporter: Juhani Connolly Priority: Minor Attachments: 6083v2.txt, hbase-6083.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6083) Modify old filter tests to use Junit4/no longer use HBaseTestCase
[ https://issues.apache.org/jira/browse/HBASE-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6083: - Status: Patch Available (was: Open) Modify old filter tests to use Junit4/no longer use HBaseTestCase - Key: HBASE-6083 URL: https://issues.apache.org/jira/browse/HBASE-6083 Project: HBase Issue Type: Improvement Reporter: Juhani Connolly Priority: Minor Attachments: 6083v2.txt, hbase-6083.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285364#comment-13285364 ] stack commented on HBASE-4720: -- Patch lgtm. Andrew? What you reckon? Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.92.1, 0.96.0, 0.94.1 Attachments: 4720_trunk.patch, 4720_trunk_v2.patch, 4720_trunk_v3.patch, HBASE-4720.trunk.v1.patch, HBASE-4720.trunk.v2.patch, HBASE-4720.trunk.v3.patch, HBASE-4720.trunk.v4.patch, HBASE-4720.trunk.v5.patch, HBASE-4720.trunk.v6.patch, HBASE-4720.trunk.v7.patch, HBASE-4720.v1.patch, HBASE-4720.v3.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6083) Modify old filter tests to use Junit4/no longer use HBaseTestCase
[ https://issues.apache.org/jira/browse/HBASE-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6083: - Status: Open (was: Patch Available) Modify old filter tests to use Junit4/no longer use HBaseTestCase - Key: HBASE-6083 URL: https://issues.apache.org/jira/browse/HBASE-6083 Project: HBase Issue Type: Improvement Reporter: Juhani Connolly Priority: Minor Attachments: 6083v2.txt, hbase-6083.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6083) Modify old filter tests to use Junit4/no longer use HBaseTestCase
[ https://issues.apache.org/jira/browse/HBASE-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6083: - Attachment: 6083v2.txt Fail seems unrelated but retrying just in case. Modify old filter tests to use Junit4/no longer use HBaseTestCase - Key: HBASE-6083 URL: https://issues.apache.org/jira/browse/HBASE-6083 Project: HBase Issue Type: Improvement Reporter: Juhani Connolly Priority: Minor Attachments: 6083v2.txt, 6083v2.txt, hbase-6083.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6083) Modify old filter tests to use Junit4/no longer use HBaseTestCase
[ https://issues.apache.org/jira/browse/HBASE-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6083: - Status: Patch Available (was: Open) Modify old filter tests to use Junit4/no longer use HBaseTestCase - Key: HBASE-6083 URL: https://issues.apache.org/jira/browse/HBASE-6083 Project: HBase Issue Type: Improvement Reporter: Juhani Connolly Priority: Minor Attachments: 6083v2.txt, 6083v2.txt, hbase-6083.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-6133) TestRestartCluster failing in 0.92
stack created HBASE-6133: Summary: TestRestartCluster failing in 0.92 Key: HBASE-6133 URL: https://issues.apache.org/jira/browse/HBASE-6133 Project: HBase Issue Type: Bug Reporter: stack This test failed a few times just now on 0.92 branch. Seems pretty basic failure. The master is not up yet and its throwing PleaseHoldException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6133) TestRestartCluster failing in 0.92
[ https://issues.apache.org/jira/browse/HBASE-6133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6133: - Attachment: waitonmaster.txt Added wait on master being initialized before test runs. Ran it in a loop. Seems to work (Failed the odd time when I looped w/o it). Committing. TestRestartCluster failing in 0.92 -- Key: HBASE-6133 URL: https://issues.apache.org/jira/browse/HBASE-6133 Project: HBase Issue Type: Bug Reporter: stack Attachments: waitonmaster.txt This test failed a few times just now on 0.92 branch. Seems pretty basic failure. The master is not up yet and its throwing PleaseHoldException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-6133) TestRestartCluster failing in 0.92
[ https://issues.apache.org/jira/browse/HBASE-6133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-6133. -- Resolution: Fixed Fix Version/s: 0.94.1 0.92.2 Assignee: stack Applied to 0.92, 0.94, and to trunk TestRestartCluster failing in 0.92 -- Key: HBASE-6133 URL: https://issues.apache.org/jira/browse/HBASE-6133 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Fix For: 0.92.2, 0.94.1 Attachments: waitonmaster.txt This test failed a few times just now on 0.92 branch. Seems pretty basic failure. The master is not up yet and its throwing PleaseHoldException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6131) Add attribution for code added by HBASE-5533 metrics
[ https://issues.apache.org/jira/browse/HBASE-6131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6131: - Attachment: 6131.txt Add metrics-core to pom as Jeff suggests. Remove files copied from yammer metrics project. Add attribution for code added by HBASE-5533 metrics Key: HBASE-6131 URL: https://issues.apache.org/jira/browse/HBASE-6131 Project: HBase Issue Type: Task Reporter: stack Priority: Blocker Attachments: 6131.txt See the comment over in https://issues.apache.org/jira/browse/HBASE-5533?focusedCommentId=13283920page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13283920 The metrics histogram code was copied w/o attribution. Fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6131) Add attribution for code added by HBASE-5533 metrics
[ https://issues.apache.org/jira/browse/HBASE-6131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6131: - Assignee: stack Status: Patch Available (was: Open) Add attribution for code added by HBASE-5533 metrics Key: HBASE-6131 URL: https://issues.apache.org/jira/browse/HBASE-6131 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Priority: Blocker Attachments: 6131.txt See the comment over in https://issues.apache.org/jira/browse/HBASE-5533?focusedCommentId=13283920page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13283920 The metrics histogram code was copied w/o attribution. Fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6083) Modify old filter tests to use Junit4/no longer use HBaseTestCase
[ https://issues.apache.org/jira/browse/HBASE-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6083: - Resolution: Fixed Fix Version/s: 0.96.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to trunk. Thanks for the patch Juhani. Modify old filter tests to use Junit4/no longer use HBaseTestCase - Key: HBASE-6083 URL: https://issues.apache.org/jira/browse/HBASE-6083 Project: HBase Issue Type: Improvement Reporter: Juhani Connolly Priority: Minor Fix For: 0.96.0 Attachments: 6083v2.txt, 6083v2.txt, hbase-6083.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-6083) Modify old filter tests to use Junit4/no longer use HBaseTestCase
[ https://issues.apache.org/jira/browse/HBASE-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reassigned HBASE-6083: Assignee: Juhani Connolly Added you as a contributor Juhani. Assigned you this issue. Modify old filter tests to use Junit4/no longer use HBaseTestCase - Key: HBASE-6083 URL: https://issues.apache.org/jira/browse/HBASE-6083 Project: HBase Issue Type: Improvement Reporter: Juhani Connolly Assignee: Juhani Connolly Priority: Minor Fix For: 0.96.0 Attachments: 6083v2.txt, 6083v2.txt, hbase-6083.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6131) Add attribution for code added by HBASE-5533 metrics
[ https://issues.apache.org/jira/browse/HBASE-6131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6131: - Attachment: 6131_094.txt Here is what I applied to 0.94 branch. Add attribution for code added by HBASE-5533 metrics Key: HBASE-6131 URL: https://issues.apache.org/jira/browse/HBASE-6131 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Priority: Blocker Attachments: 6131.txt, 6131_094.txt See the comment over in https://issues.apache.org/jira/browse/HBASE-5533?focusedCommentId=13283920page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13283920 The metrics histogram code was copied w/o attribution. Fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-4720: - Status: Open (was: Patch Available) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.96.0, 0.94.1, 0.92.1 Attachments: 4720_trunk.patch, 4720_trunk_v2.patch, 4720_trunk_v3.1.patch, 4720_trunk_v3.patch, HBASE-4720.trunk.v1.patch, HBASE-4720.trunk.v2.patch, HBASE-4720.trunk.v3.patch, HBASE-4720.trunk.v4.patch, HBASE-4720.trunk.v5.patch, HBASE-4720.trunk.v6.patch, HBASE-4720.trunk.v7.patch, HBASE-4720.v1.patch, HBASE-4720.v3.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-4720: - Attachment: 4720_trunk_v3.patch Retry just in case Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.92.1, 0.96.0, 0.94.1 Attachments: 4720_trunk.patch, 4720_trunk_v2.patch, 4720_trunk_v3.1.patch, 4720_trunk_v3.patch, 4720_trunk_v3.patch, HBASE-4720.trunk.v1.patch, HBASE-4720.trunk.v2.patch, HBASE-4720.trunk.v3.patch, HBASE-4720.trunk.v4.patch, HBASE-4720.trunk.v5.patch, HBASE-4720.trunk.v6.patch, HBASE-4720.trunk.v7.patch, HBASE-4720.v1.patch, HBASE-4720.v3.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-4720: - Status: Patch Available (was: Open) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.96.0, 0.94.1, 0.92.1 Attachments: 4720_trunk.patch, 4720_trunk_v2.patch, 4720_trunk_v3.1.patch, 4720_trunk_v3.patch, 4720_trunk_v3.patch, HBASE-4720.trunk.v1.patch, HBASE-4720.trunk.v2.patch, HBASE-4720.trunk.v3.patch, HBASE-4720.trunk.v4.patch, HBASE-4720.trunk.v5.patch, HBASE-4720.trunk.v6.patch, HBASE-4720.trunk.v7.patch, HBASE-4720.v1.patch, HBASE-4720.v3.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6109) Improve RIT performances during assignment on large clusters
[ https://issues.apache.org/jira/browse/HBASE-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6109: - Status: Patch Available (was: Open) Improve RIT performances during assignment on large clusters Key: HBASE-6109 URL: https://issues.apache.org/jira/browse/HBASE-6109 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.96.0 Reporter: nkeywal Assignee: nkeywal Priority: Minor Fix For: 0.96.0 Attachments: 6109.v19.patch, 6109.v21.patch, 6109.v7.patch The main points in this patch are: - lowering the number of copy of the RIT list - lowering the number of synchronization - synchronizing on a region rather than on everything It also contains: - some fixes around the RIT notification: the list was sometimes modified without a corresponding 'notify'. - some tests flakiness correction, actually unrelated to this patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6049) Serializing List containing null elements will cause NullPointerException in HbaseObjectWritable.writeObject()
[ https://issues.apache.org/jira/browse/HBASE-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6049: - Resolution: Fixed Status: Resolved (was: Patch Available) Committed to 0.94 and trunk. Thanks for the patch Maryann and thanks for rebasing Ted. Serializing List containing null elements will cause NullPointerException in HbaseObjectWritable.writeObject() Key: HBASE-6049 URL: https://issues.apache.org/jira/browse/HBASE-6049 Project: HBase Issue Type: Bug Components: io Affects Versions: 0.94.0 Reporter: Maryann Xue Fix For: 0.96.0, 0.94.1 Attachments: 6049-v3.patch, HBASE-6049-v2.patch, HBASE-6049-v3.patch, HBASE-6049.patch An error case could be in Coprocessor AggregationClient, the median() function handles an empty region and returns a List Object with the first element as a Null value. NPE occurs in the RPC response stage and the response never gets sent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6049) Serializing List containing null elements will cause NullPointerException in HbaseObjectWritable.writeObject()
[ https://issues.apache.org/jira/browse/HBASE-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285852#comment-13285852 ] stack commented on HBASE-6049: -- @Maryann I am having trouble adding you as a committer. Will keep trying. Serializing List containing null elements will cause NullPointerException in HbaseObjectWritable.writeObject() Key: HBASE-6049 URL: https://issues.apache.org/jira/browse/HBASE-6049 Project: HBase Issue Type: Bug Components: io Affects Versions: 0.94.0 Reporter: Maryann Xue Fix For: 0.96.0, 0.94.1 Attachments: 6049-v3.patch, HBASE-6049-v2.patch, HBASE-6049-v3.patch, HBASE-6049.patch An error case could be in Coprocessor AggregationClient, the median() function handles an empty region and returns a List Object with the first element as a Null value. NPE occurs in the RPC response stage and the response never gets sent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6089) SSH and AM.joinCluster causes Concurrent Modification exception.
[ https://issues.apache.org/jira/browse/HBASE-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285863#comment-13285863 ] stack commented on HBASE-6089: -- bq. What you feel? If it is ok for you , i can commit this? Yes. Its no good adding a CSLM as I suggested because the sync block is needed to cover regions and servers updates (as Anoop says). SSH and AM.joinCluster causes Concurrent Modification exception. Key: HBASE-6089 URL: https://issues.apache.org/jira/browse/HBASE-6089 Project: HBase Issue Type: Bug Affects Versions: 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: rajeshbabu Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-6089_92.patch, HBASE-6089_94.patch, HBASE-6089_trunk.patch AM.regions map is parallely accessed in SSH and Master initialization leading to ConcurrentModificationException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-4720: - Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to 0.92, 0.94 and trunk. Thanks for the patch Jimmy and Mubarak. Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.96.0, 0.94.1, 0.92.1 Attachments: 4720_trunk.patch, 4720_trunk_v2.patch, 4720_trunk_v3.1.patch, 4720_trunk_v3.patch, 4720_trunk_v3.patch, HBASE-4720.trunk.v1.patch, HBASE-4720.trunk.v2.patch, HBASE-4720.trunk.v3.patch, HBASE-4720.trunk.v4.patch, HBASE-4720.trunk.v5.patch, HBASE-4720.trunk.v6.patch, HBASE-4720.trunk.v7.patch, HBASE-4720.v1.patch, HBASE-4720.v3.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6109) Improve RIT performances during assignment on large clusters
[ https://issues.apache.org/jira/browse/HBASE-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285914#comment-13285914 ] stack commented on HBASE-6109: -- Thanks N. Improve RIT performances during assignment on large clusters Key: HBASE-6109 URL: https://issues.apache.org/jira/browse/HBASE-6109 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.96.0 Reporter: nkeywal Assignee: nkeywal Priority: Minor Fix For: 0.96.0 Attachments: 6109.v19.patch, 6109.v21.patch, 6109.v7.patch The main points in this patch are: - lowering the number of copy of the RIT list - lowering the number of synchronization - synchronizing on a region rather than on everything It also contains: - some fixes around the RIT notification: the list was sometimes modified without a corresponding 'notify'. - some tests flakiness correction, actually unrelated to this patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6135) Style the Web UI to use Twitter's Bootstrap.
[ https://issues.apache.org/jira/browse/HBASE-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6135: - Tags: noob Style the Web UI to use Twitter's Bootstrap. Key: HBASE-6135 URL: https://issues.apache.org/jira/browse/HBASE-6135 Project: HBase Issue Type: Improvement Reporter: Elliott Clark Fix For: 0.96.0 Our web ui has lagged a little bit behind. While it's not a huge deal, it is one of the first things that new people see. As such styling it a little bit better would put a good foot forward. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6134) Improvement for split-worker to speed up distributed-split-log
[ https://issues.apache.org/jira/browse/HBASE-6134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6134: - Priority: Critical (was: Major) Marking critical. This improves our MTTR. Improvement for split-worker to speed up distributed-split-log -- Key: HBASE-6134 URL: https://issues.apache.org/jira/browse/HBASE-6134 Project: HBase Issue Type: Improvement Components: wal Reporter: chunhui shen Assignee: chunhui shen Priority: Critical Fix For: 0.96.0 Attachments: HBASE-6134.patch First，we do the test between local-master-split and distributed split log Environment：34 hlog files, 5 regionservers,(after kill one, only 4 rs do ths splitting work) local-master-split:60s+ distributed-split-log:165s+ In fact, in our production environment, distributed-split-log also took 60s with 30 regionservers for 34 hlog files (regionserver may be in high load) We found split-worker split one log file took about 20s. I think we should do the improvement for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5959) Add other load balancers
[ https://issues.apache.org/jira/browse/HBASE-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285941#comment-13285941 ] stack commented on HBASE-5959: -- I'll commit this this afternoon unless objection (old behavior is the default). Add other load balancers Key: HBASE-5959 URL: https://issues.apache.org/jira/browse/HBASE-5959 Project: HBase Issue Type: New Feature Components: master Affects Versions: 0.96.0 Reporter: Elliott Clark Assignee: Elliott Clark Attachments: HBASE-5959-0.patch, HBASE-5959-1.patch, HBASE-5959-11.patch, HBASE-5959-12.patch, HBASE-5959-13.patch, HBASE-5959-2.patch, HBASE-5959-3.patch, HBASE-5959-6.patch, HBASE-5959-7.patch, HBASE-5959-8.patch, HBASE-5959-9.patch, HBASE-5959.D3189.1.patch, HBASE-5959.D3189.2.patch, HBASE-5959.D3189.3.patch, HBASE-5959.D3189.4.patch, HBASE-5959.D3189.5.patch, HBASE-5959.D3189.6.patch, HBASE-5959.D3189.7.patch Now that balancers are pluggable we should give some options.b -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5609) Add the ability to pass additional information for slow query logging
[ https://issues.apache.org/jira/browse/HBASE-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285945#comment-13285945 ] stack commented on HBASE-5609: -- @Michael Looks good. Most of time id will be null though, right? In that case, should we skip setting id on a Put, Get, Scan? Otherwise looks good to me. Add the ability to pass additional information for slow query logging - Key: HBASE-5609 URL: https://issues.apache.org/jira/browse/HBASE-5609 Project: HBase Issue Type: New Feature Components: client, ipc Reporter: Michael Drzal Assignee: Michael Drzal Priority: Minor Attachments: HBASE-5609.patch HBase-4117 added the ability to log information about queries that returned too much data or ran for too long. There is some information written as a fingerprint that can be used to tell what table/column families/... are affected. I would like to extend this functionality to allow the client to insert an identifier into the operation that gets output in the log. The idea behind this would be that if there were N places in the client application that touched a given table in a certain way, you could quickly narrow things down by inserting a className:functionName or similar identifier. I'm fully willing to go back on this if people think that it isn't a problem in real life and it would just add complexity to the code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6091) Come up with strawman proposal for RC testing matrix
[ https://issues.apache.org/jira/browse/HBASE-6091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285950#comment-13285950 ] stack commented on HBASE-6091: -- This seems like good candidate for wiki page at least until it hardens some. Thereafter, it could go into the reference guide? Good on you David. Come up with strawman proposal for RC testing matrix Key: HBASE-6091 URL: https://issues.apache.org/jira/browse/HBASE-6091 Project: HBase Issue Type: Bug Components: documentation Affects Versions: 0.96.0 Reporter: David S. Wang Assignee: David S. Wang -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6062) preCheckAndPut/Delete() checks for READ when also a WRITE is performed
[ https://issues.apache.org/jira/browse/HBASE-6062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285953#comment-13285953 ] stack commented on HBASE-6062: -- @Matteo Want to update the patch as Andrew suggests? Thanks. preCheckAndPut/Delete() checks for READ when also a WRITE is performed -- Key: HBASE-6062 URL: https://issues.apache.org/jira/browse/HBASE-6062 Project: HBase Issue Type: Sub-task Components: security Affects Versions: 0.92.1, 0.94.0, 0.96.0 Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Labels: acl, security Fix For: 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-6062-v0.patch preCheckAndPut() and preCheckAndDelete() checks for READ when they also want to WRITE... for me checking for WRITE permission is the right thing... what do you say about that? keep READ, replace with WRITE? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5932) Move RegionServerStatusProtocol from ipc package to top-level
[ https://issues.apache.org/jira/browse/HBASE-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-5932: - Resolution: Fixed Fix Version/s: 0.96.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to trunk. Thanks for the patch Gregory. Move RegionServerStatusProtocol from ipc package to top-level - Key: HBASE-5932 URL: https://issues.apache.org/jira/browse/HBASE-5932 Project: HBase Issue Type: Task Affects Versions: 0.96.0 Reporter: Gregory Chanan Assignee: Gregory Chanan Priority: Trivial Fix For: 0.96.0 Attachments: HBASE-5932-v2.patch, HBASE-5932.patch From Stack's comment on HBASE-5444: We can move the ipc protocol stuff to top level later... I was thinking that these classes shared by master and regionservers could be at o.a.h.h... but can do that later if it makes sense. Lets get this pb stuff in first. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5936) Add Column-level PB-based calls to HMasterInterface
[ https://issues.apache.org/jira/browse/HBASE-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-5936: - Resolution: Fixed Hadoop Flags: Incompatible change,Reviewed Status: Resolved (was: Patch Available) Committed to trunk. Thanks for the patch Gregory. Add Column-level PB-based calls to HMasterInterface --- Key: HBASE-5936 URL: https://issues.apache.org/jira/browse/HBASE-5936 Project: HBase Issue Type: Task Components: ipc, master, migration Reporter: Gregory Chanan Assignee: Gregory Chanan Fix For: 0.96.0 Attachments: HBASE-5936.patch This should be a subtask of HBASE-5445, but since that is a subtask, I can't also make this a subtask (apparently). This is for converting the column-level calls, i.e.: addColumn deleteColumn modifyColumn -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6129) Backport of Add Increment Coalescing in thrift.
[ https://issues.apache.org/jira/browse/HBASE-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6129: - Resolution: Fixed Fix Version/s: 0.94.1 Assignee: Elliott Clark Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to 0.94. Thanks for the patch Elliott. Backport of Add Increment Coalescing in thrift. --- Key: HBASE-6129 URL: https://issues.apache.org/jira/browse/HBASE-6129 Project: HBase Issue Type: Task Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 0.94.1 Attachments: HBASE-6129-0.patch backport HBASE-6043 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6087) Add hbase-common module
[ https://issues.apache.org/jira/browse/HBASE-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285974#comment-13285974 ] stack commented on HBASE-6087: -- bq except surefire runs by default in all non-pom modules. I don't grok the above. Is it possible at all running just the hbase-common unit tests w/o having to run all module tests? If so, do I have to do the invocation from parent dir or can I do it in the hbase-common module? (Like Matt, apologize if I'm being particularly thick on this one). Add hbase-common module --- Key: HBASE-6087 URL: https://issues.apache.org/jira/browse/HBASE-6087 Project: HBase Issue Type: Bug Components: build Affects Versions: 0.96.0 Reporter: Jesse Yates Assignee: Jesse Yates Attachments: hbase-6087-v0.patch, hbase-6087-v1.patch Add an hbase-common module so common/utility classes can be pulled up out of hbase-server. This is _not_ the moving of classes, just the general project setup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6087) Add hbase-common module
[
https://issues.apache.org/jira/browse/HBASE-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285979#comment-13285979
]
stack commented on HBASE-6087:
--
Why this change in a patch that adds a new module?
{code}
+# For releases, add hbase webapps to CLASSPATH
+# Webapps must come first else it messes up Jetty
+if [ -d $HBASE_HOME/hbase-webapps ]; then
+ add_to_cp_if_exists ${HBASE_HOME}
+fi
+#add if we are in a dev environment
+if [ -d $HBASE_HOME/hbase-server/target/hbase-webapps ]; then
+ add_to_cp_if_exists ${HBASE_HOME}/hbase-server/target
+fi
{code}
Why is it being moved earlier?
Doesn't this get inherited from parent? +
version0.95-SNAPSHOT/version (This is version of the new hbase-common
pom.xml).
This comment is wrong?
{code}
+!--
+ profile for building against Hadoop 0.23.0. Activate using:
+ mvn -Dhadoop.profile=23
+--
{code}
Thats good HBaseConfiguration comes up. HConstants too? That think is an ugly
anti-pattern. I'm fine w/ it going up but need to figure how to kill it.
I'm +1 on committing this. Good stuff Jesse. Is it ready to go you think?
Add hbase-common module
---
Key: HBASE-6087
URL: https://issues.apache.org/jira/browse/HBASE-6087
Project: HBase
Issue Type: Bug
Components: build
Affects Versions: 0.96.0
Reporter: Jesse Yates
Assignee: Jesse Yates
Attachments: hbase-6087-v0.patch, hbase-6087-v1.patch
Add an hbase-common module so common/utility classes can be pulled up out of
hbase-server. This is _not_ the moving of classes, just the general project
setup.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6087) Add hbase-common module
[ https://issues.apache.org/jira/browse/HBASE-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6087: - Status: Patch Available (was: Open) Add hbase-common module --- Key: HBASE-6087 URL: https://issues.apache.org/jira/browse/HBASE-6087 Project: HBase Issue Type: Bug Components: build Affects Versions: 0.96.0 Reporter: Jesse Yates Assignee: Jesse Yates Attachments: hbase-6087-v0.patch, hbase-6087-v1.patch Add an hbase-common module so common/utility classes can be pulled up out of hbase-server. This is _not_ the moving of classes, just the general project setup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5936) Add Column-level PB-based calls to HMasterInterface
[ https://issues.apache.org/jira/browse/HBASE-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285984#comment-13285984 ] stack commented on HBASE-5936: -- @Gregory Yes please. I should have been less enthusiastic about commit. If you can't work on it today, I can back this out. Add Column-level PB-based calls to HMasterInterface --- Key: HBASE-5936 URL: https://issues.apache.org/jira/browse/HBASE-5936 Project: HBase Issue Type: Task Components: ipc, master, migration Reporter: Gregory Chanan Assignee: Gregory Chanan Fix For: 0.96.0 Attachments: HBASE-5936.patch This should be a subtask of HBASE-5445, but since that is a subtask, I can't also make this a subtask (apparently). This is for converting the column-level calls, i.e.: addColumn deleteColumn modifyColumn -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6124) Backport HBASE-6033 to 0.90, 0.92 and 0.94
[ https://issues.apache.org/jira/browse/HBASE-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6124: - Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to 0.90, 0.92 and 0.94. Thanks for the patch Jimmy. Backport HBASE-6033 to 0.90, 0.92 and 0.94 -- Key: HBASE-6124 URL: https://issues.apache.org/jira/browse/HBASE-6124 Project: HBase Issue Type: Improvement Affects Versions: 0.90.6, 0.92.1, 0.94.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Minor Fix For: 0.90.7, 0.94.1, 0.92.1 Attachments: patch-0.90.txt, patch-0.92.txt, patch-0.94.txt HBASE-6033 is pushed into 0.96. It's better to have it for previous version too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (HBASE-5936) Add Column-level PB-based calls to HMasterInterface
[ https://issues.apache.org/jira/browse/HBASE-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reopened HBASE-5936: -- Let me just reopen this altogether. I'll back it out. You can add fix to a new version of the patch Gregory. Thanks. Add Column-level PB-based calls to HMasterInterface --- Key: HBASE-5936 URL: https://issues.apache.org/jira/browse/HBASE-5936 Project: HBase Issue Type: Task Components: ipc, master, migration Reporter: Gregory Chanan Assignee: Gregory Chanan Fix For: 0.96.0 Attachments: HBASE-5936.patch This should be a subtask of HBASE-5445, but since that is a subtask, I can't also make this a subtask (apparently). This is for converting the column-level calls, i.e.: addColumn deleteColumn modifyColumn -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5959) Add other load balancers
[ https://issues.apache.org/jira/browse/HBASE-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286015#comment-13286015 ] stack commented on HBASE-5959: -- @Ted If you run w/o this patch, that test passes and then if you run w/ this patch it always fails? That test seems totally unrelated to whats going on in this patch. Add other load balancers Key: HBASE-5959 URL: https://issues.apache.org/jira/browse/HBASE-5959 Project: HBase Issue Type: New Feature Components: master Affects Versions: 0.96.0 Reporter: Elliott Clark Assignee: Elliott Clark Attachments: HBASE-5959-0.patch, HBASE-5959-1.patch, HBASE-5959-11.patch, HBASE-5959-12.patch, HBASE-5959-13.patch, HBASE-5959-14.patch, HBASE-5959-2.patch, HBASE-5959-3.patch, HBASE-5959-6.patch, HBASE-5959-7.patch, HBASE-5959-8.patch, HBASE-5959-9.patch, HBASE-5959.D3189.1.patch, HBASE-5959.D3189.2.patch, HBASE-5959.D3189.3.patch, HBASE-5959.D3189.4.patch, HBASE-5959.D3189.5.patch, HBASE-5959.D3189.6.patch, HBASE-5959.D3189.7.patch Now that balancers are pluggable we should give some options.b -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6059) Replaying recovered edits would make deleted data exist again
[ https://issues.apache.org/jira/browse/HBASE-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286024#comment-13286024 ] stack commented on HBASE-6059: -- +1 Great work @Chunhui. Nice find. Nice tests too. Replaying recovered edits would make deleted data exist again - Key: HBASE-6059 URL: https://issues.apache.org/jira/browse/HBASE-6059 Project: HBase Issue Type: Bug Components: regionserver Reporter: chunhui shen Assignee: chunhui shen Attachments: 6059v6.txt, HBASE-6059-testcase.patch, HBASE-6059.patch, HBASE-6059v2.patch, HBASE-6059v3.patch, HBASE-6059v4.patch, HBASE-6059v5.patch When we replay recovered edits, we used the minSeqId of Store, It may cause deleted data appeared again. Let's see how it happens. Suppose the region with two families(cf1,cf2) 1.put one data to the region (put r1,cf1:q1,v1) 2.move the region from server A to server B. 3.delete the data put by step 1(delete r1) 4.flush this region. 5.make major compaction for this region 6.move the region from server B to server A. 7.Abort server A 8.After the region is online, we could get the deleted data(r1,cf1:q1,v1) (When we replay recovered edits, we used the minSeqId of Store, because cf2 has no store files, so its seqId is 0, so the edit log of put data will be replayed to the region) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6068) Secure HBase cluster : Client not able to call some admin APIs
[ https://issues.apache.org/jira/browse/HBASE-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6068: - Resolution: Fixed Fix Version/s: 0.94.1 0.92.2 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Secure HBase cluster : Client not able to call some admin APIs -- Key: HBASE-6068 URL: https://issues.apache.org/jira/browse/HBASE-6068 Project: HBase Issue Type: Bug Components: security Affects Versions: 0.92.1, 0.94.0, 0.96.0 Reporter: Anoop Sam John Assignee: Matteo Bertozzi Fix For: 0.92.2, 0.94.1 Attachments: HBASE-6068-v0.patch, HBASE-6068-v1.patch, HBASE-6068-v2.patch, HBASE-6068-v3.patch In case of secure cluster, we allow the HBase clients to read the zk nodes by providing the global read permissions to all for certain nodes. These nodes are the master address znode, root server znode and the clusterId znode. In ZKUtil.createACL() , we can see these node names are specially handled. But there are some other client side admin APIs which makes a read call into the zookeeper from the client. This include the isTableEnabled() call (May be some other. I have seen this). Here the client directly reads a node in the zookeeper ( node created for this table ) and the data is matched to know whether this is enabled or not. Now in secure cluster case any client can read zookeeper nodes which it needs for its normal operation like the master address and root server address. But what if the client calls this API? [isTableEnaled () ]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6068) Secure HBase cluster : Client not able to call some admin APIs
[ https://issues.apache.org/jira/browse/HBASE-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6068: - Fix Version/s: (was: 0.94.1) (was: 0.92.2) 0.96.0 Secure HBase cluster : Client not able to call some admin APIs -- Key: HBASE-6068 URL: https://issues.apache.org/jira/browse/HBASE-6068 Project: HBase Issue Type: Bug Components: security Affects Versions: 0.92.1, 0.94.0, 0.96.0 Reporter: Anoop Sam John Assignee: Matteo Bertozzi Fix For: 0.96.0 Attachments: HBASE-6068-v0.patch, HBASE-6068-v1.patch, HBASE-6068-v2.patch, HBASE-6068-v3.patch In case of secure cluster, we allow the HBase clients to read the zk nodes by providing the global read permissions to all for certain nodes. These nodes are the master address znode, root server znode and the clusterId znode. In ZKUtil.createACL() , we can see these node names are specially handled. But there are some other client side admin APIs which makes a read call into the zookeeper from the client. This include the isTableEnabled() call (May be some other. I have seen this). Here the client directly reads a node in the zookeeper ( node created for this table ) and the data is matched to know whether this is enabled or not. Now in secure cluster case any client can read zookeeper nodes which it needs for its normal operation like the master address and root server address. But what if the client calls this API? [isTableEnaled () ]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5959) Add other load balancers
[ https://issues.apache.org/jira/browse/HBASE-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286034#comment-13286034 ] stack commented on HBASE-5959: -- @Ted np Sorry about that. I'll go ahead and commit this. Add other load balancers Key: HBASE-5959 URL: https://issues.apache.org/jira/browse/HBASE-5959 Project: HBase Issue Type: New Feature Components: master Affects Versions: 0.96.0 Reporter: Elliott Clark Assignee: Elliott Clark Attachments: HBASE-5959-0.patch, HBASE-5959-1.patch, HBASE-5959-11.patch, HBASE-5959-12.patch, HBASE-5959-13.patch, HBASE-5959-14.patch, HBASE-5959-2.patch, HBASE-5959-3.patch, HBASE-5959-6.patch, HBASE-5959-7.patch, HBASE-5959-8.patch, HBASE-5959-9.patch, HBASE-5959.D3189.1.patch, HBASE-5959.D3189.2.patch, HBASE-5959.D3189.3.patch, HBASE-5959.D3189.4.patch, HBASE-5959.D3189.5.patch, HBASE-5959.D3189.6.patch, HBASE-5959.D3189.7.patch Now that balancers are pluggable we should give some options.b -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (HBASE-6122) Backup master does not become Active master after ZK exception
[
https://issues.apache.org/jira/browse/HBASE-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack reopened HBASE-6122:
--
Reopening. Backing out these patches. It seems reponsible for these failures:
https://builds.apache.org/job/HBase-0.92/433/
Backup master does not become Active master after ZK exception
--
Key: HBASE-6122
URL: https://issues.apache.org/jira/browse/HBASE-6122
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.0
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
Fix For: 0.92.2, 0.94.1
Attachments: HBASE-6122_0.92.patch, HBASE-6122_0.94.patch
- Active master gets ZK expiry exception.
- Backup master becomes active.
- The previous active master retries and becomes the back up master.
Now when the new active master goes down and the current back up master comes
up, it goes down again with the zk expiry exception it got in the first step.
{code}
if (abortNow(msg, t)) {
if (t != null) LOG.fatal(msg, t);
else LOG.fatal(msg);
this.abort = true;
stop(Aborting);
}
{code}
In ActiveMasterManager.blockUntilBecomingActiveMaster we try to wait till the
back up master becomes active.
{code}
synchronized (this.clusterHasActiveMaster) {
while (this.clusterHasActiveMaster.get() !this.master.isStopped()) {
try {
this.clusterHasActiveMaster.wait();
} catch (InterruptedException e) {
// We expect to be interrupted when a master dies, will fall out if
so
LOG.debug(Interrupted waiting for master to die, e);
}
}
if (!clusterStatusTracker.isClusterUp()) {
this.master.stop(Cluster went down before this master became
active);
}
if (this.master.isStopped()) {
return cleanSetOfActiveMaster;
}
// Try to become active master again now that there is no active master
blockUntilBecomingActiveMaster(startupStatus,clusterStatusTracker);
}
return cleanSetOfActiveMaster;
{code}
When the back up master (it is in back up mode as he got ZK exception), once
again tries to come to active we don't get the return value that comes out
from
{code}
// Try to become active master again now that there is no active master
blockUntilBecomingActiveMaster(startupStatus,clusterStatusTracker);
{code}
We tend to return the 'cleanSetOfActiveMaster' which was previously false.
Now because of this instead of again becoming active the back up master goes
down in the abort() code. Thanks to Gopi,my colleague for reporting this
issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6122) Backup master does not become Active master after ZK exception
[
https://issues.apache.org/jira/browse/HBASE-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286072#comment-13286072
]
stack commented on HBASE-6122:
--
I reverted from 0.92 and 0.94 branches till we figure the failures.
Backup master does not become Active master after ZK exception
--
Key: HBASE-6122
URL: https://issues.apache.org/jira/browse/HBASE-6122
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.0
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
Fix For: 0.92.2, 0.94.1
Attachments: HBASE-6122_0.92.patch, HBASE-6122_0.94.patch
- Active master gets ZK expiry exception.
- Backup master becomes active.
- The previous active master retries and becomes the back up master.
Now when the new active master goes down and the current back up master comes
up, it goes down again with the zk expiry exception it got in the first step.
{code}
if (abortNow(msg, t)) {
if (t != null) LOG.fatal(msg, t);
else LOG.fatal(msg);
this.abort = true;
stop(Aborting);
}
{code}
In ActiveMasterManager.blockUntilBecomingActiveMaster we try to wait till the
back up master becomes active.
{code}
synchronized (this.clusterHasActiveMaster) {
while (this.clusterHasActiveMaster.get() !this.master.isStopped()) {
try {
this.clusterHasActiveMaster.wait();
} catch (InterruptedException e) {
// We expect to be interrupted when a master dies, will fall out if
so
LOG.debug(Interrupted waiting for master to die, e);
}
}
if (!clusterStatusTracker.isClusterUp()) {
this.master.stop(Cluster went down before this master became
active);
}
if (this.master.isStopped()) {
return cleanSetOfActiveMaster;
}
// Try to become active master again now that there is no active master
blockUntilBecomingActiveMaster(startupStatus,clusterStatusTracker);
}
return cleanSetOfActiveMaster;
{code}
When the back up master (it is in back up mode as he got ZK exception), once
again tries to come to active we don't get the return value that comes out
from
{code}
// Try to become active master again now that there is no active master
blockUntilBecomingActiveMaster(startupStatus,clusterStatusTracker);
{code}
We tend to return the 'cleanSetOfActiveMaster' which was previously false.
Now because of this instead of again becoming active the back up master goes
down in the abort() code. Thanks to Gopi,my colleague for reporting this
issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6068) Secure HBase cluster : Client not able to call some admin APIs
[ https://issues.apache.org/jira/browse/HBASE-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286076#comment-13286076 ] stack commented on HBASE-6068: -- Applied the 0.92 patch to 0.92 and 0.94 branches. Thanks Matteo. Secure HBase cluster : Client not able to call some admin APIs -- Key: HBASE-6068 URL: https://issues.apache.org/jira/browse/HBASE-6068 Project: HBase Issue Type: Bug Components: security Affects Versions: 0.92.1, 0.94.0, 0.96.0 Reporter: Anoop Sam John Assignee: Matteo Bertozzi Fix For: 0.92.2, 0.94.1 Attachments: HBASE-6068-0.92.patch, HBASE-6068-v0.patch, HBASE-6068-v1.patch, HBASE-6068-v2.patch, HBASE-6068-v3.patch In case of secure cluster, we allow the HBase clients to read the zk nodes by providing the global read permissions to all for certain nodes. These nodes are the master address znode, root server znode and the clusterId znode. In ZKUtil.createACL() , we can see these node names are specially handled. But there are some other client side admin APIs which makes a read call into the zookeeper from the client. This include the isTableEnabled() call (May be some other. I have seen this). Here the client directly reads a node in the zookeeper ( node created for this table ) and the data is matched to know whether this is enabled or not. Now in secure cluster case any client can read zookeeper nodes which it needs for its normal operation like the master address and root server address. But what if the client calls this API? [isTableEnaled () ]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6068) Secure HBase cluster : Client not able to call some admin APIs
[ https://issues.apache.org/jira/browse/HBASE-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6068: - Fix Version/s: (was: 0.96.0) 0.94.1 0.92.2 Secure HBase cluster : Client not able to call some admin APIs -- Key: HBASE-6068 URL: https://issues.apache.org/jira/browse/HBASE-6068 Project: HBase Issue Type: Bug Components: security Affects Versions: 0.92.1, 0.94.0, 0.96.0 Reporter: Anoop Sam John Assignee: Matteo Bertozzi Fix For: 0.92.2, 0.94.1 Attachments: HBASE-6068-0.92.patch, HBASE-6068-v0.patch, HBASE-6068-v1.patch, HBASE-6068-v2.patch, HBASE-6068-v3.patch In case of secure cluster, we allow the HBase clients to read the zk nodes by providing the global read permissions to all for certain nodes. These nodes are the master address znode, root server znode and the clusterId znode. In ZKUtil.createACL() , we can see these node names are specially handled. But there are some other client side admin APIs which makes a read call into the zookeeper from the client. This include the isTableEnabled() call (May be some other. I have seen this). Here the client directly reads a node in the zookeeper ( node created for this table ) and the data is matched to know whether this is enabled or not. Now in secure cluster case any client can read zookeeper nodes which it needs for its normal operation like the master address and root server address. But what if the client calls this API? [isTableEnaled () ]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-2396) Coprocessors: Server side dynamic scripting language execution
[ https://issues.apache.org/jira/browse/HBASE-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-2396: - Tags: noob Labels: noob (was: ) This'd be a fun/crazy noob project. Coprocessors: Server side dynamic scripting language execution -- Key: HBASE-2396 URL: https://issues.apache.org/jira/browse/HBASE-2396 Project: HBase Issue Type: New Feature Components: coprocessors Reporter: Todd Lipcon Assignee: Andrew Purtell Labels: noob There are a lot of use cases where users want to perform some simple operations on the region server. For example, a row may represent a Set and users want append/search/remove style operations within the row without having to perform the work on the client side. One possible solution is to embed a small language something like PL/SQL (not necessarily in syntax) which restricts users to a safe set of operations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6032) Port HFileBlockIndex improvement from HBASE-5987
[ https://issues.apache.org/jira/browse/HBASE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286092#comment-13286092 ] stack commented on HBASE-6032: -- Thanks for forward porting Ted. Weird this patch uses TestHBaseCase and does all this fixup in it -- its a deprecated class -- and that it makes data members static. Otherwise, patch is great on cursory review. Port HFileBlockIndex improvement from HBASE-5987 Key: HBASE-6032 URL: https://issues.apache.org/jira/browse/HBASE-6032 Project: HBase Issue Type: Task Reporter: Zhihong Yu Assignee: Zhihong Yu Fix For: 0.96.0 Attachments: 6032-ports-5987-v2.txt, 6032-ports-5987.txt Excerpt from HBASE-5987: First, we propose to lookahead for one more block index so that the HFileScanner would know the start key value of next data block. So if the target key value for the scan(reSeekTo) is smaller than that start kv of next data block, it means the target key value has a very high possibility in the current data block (if not in current data block, then the start kv of next data block should be returned. +Indexing on the start key has some defects here+) and it shall NOT query the HFileBlockIndex in this case. On the contrary, if the target key value is bigger, then it shall query the HFileBlockIndex. This improvement shall help to reduce the hotness of HFileBlockIndex and avoid some unnecessary IdLock Contention or Index Block Cache lookup. This JIRA is to port the fix to HBase trunk, etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6120) Few logging improvements around enabling tables
[ https://issues.apache.org/jira/browse/HBASE-6120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6120: - Resolution: Fixed Fix Version/s: 0.96.0 Assignee: Harsh J Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Applied to trunk. Thanks for the patch Harsh. Few logging improvements around enabling tables --- Key: HBASE-6120 URL: https://issues.apache.org/jira/browse/HBASE-6120 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.94.0 Reporter: Harsh J Assignee: Harsh J Priority: Trivial Fix For: 0.96.0 Attachments: HBASE-6120.patch - Few log statements between Enable/Disable/Create table handler event classes have a typo with word Attempting (its misspelled Attemping). - Even upon an enable operation's failure, the tailing message is a mere INFO with a state of 'false'. This isn't as visible as I'd like it to be when diagnosing logs for issues. I've put it in a proper if-else for this case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6119) Region server logs its own address at the end of getMaster()
[
https://issues.apache.org/jira/browse/HBASE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286095#comment-13286095
]
stack commented on HBASE-6119:
--
+1
Region server logs its own address at the end of getMaster()
Key: HBASE-6119
URL: https://issues.apache.org/jira/browse/HBASE-6119
Project: HBase
Issue Type: Bug
Reporter: Zhihong Yu
Priority: Minor
Fix For: 0.96.0
Attachments: 6119-trunk.txt
I saw the following in region server log where a.ebay.com is region server
itself:
{code}
2012-05-28 08:56:35,315 INFO
org.apache.hadoop.hbase.regionserver.HRegionServer: Connected to master at
a.ebay.com/10.115.13.20:60020
{code}
We should be logging the address of master
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6040) Use block encoding and HBase handled checksum verification in bulk loading using HFileOutputFormat
[ https://issues.apache.org/jira/browse/HBASE-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286100#comment-13286100 ] stack commented on HBASE-6040: -- +1 Make a trunk patch Anoop and submit it to hadoopqa? Use block encoding and HBase handled checksum verification in bulk loading using HFileOutputFormat -- Key: HBASE-6040 URL: https://issues.apache.org/jira/browse/HBASE-6040 Project: HBase Issue Type: Improvement Components: mapreduce Reporter: Anoop Sam John Assignee: Anoop Sam John Attachments: HBASE-6040_94.patch When the data is bulk loaded using HFileOutputFormat, we are not using the block encoding and the HBase handled checksum features.. When the writer is created for making the HFile, I am not seeing any such info passing to the WriterBuilder. In HFileOutputFormat.getNewWriter(byte[] family, Configuration conf), we dont have these info and do not pass also to the writer... So those HFiles will not have these optimizations.. Later in LoadIncrementalHFiles.copyHFileHalf(), where we physically divide one HFile(created by the MR) iff it can not belong to just one region, I can see we pass the datablock encoding details and checksum details to the new HFile writer. But this step wont happen normally I think.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6032) Port HFileBlockIndex improvement from HBASE-5987
[ https://issues.apache.org/jira/browse/HBASE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286102#comment-13286102 ] stack commented on HBASE-6032: -- @Liyin Yeah. We should port them over. One day! Port HFileBlockIndex improvement from HBASE-5987 Key: HBASE-6032 URL: https://issues.apache.org/jira/browse/HBASE-6032 Project: HBase Issue Type: Task Reporter: Zhihong Yu Assignee: Zhihong Yu Fix For: 0.96.0 Attachments: 6032-ports-5987-v2.txt, 6032-ports-5987.txt Excerpt from HBASE-5987: First, we propose to lookahead for one more block index so that the HFileScanner would know the start key value of next data block. So if the target key value for the scan(reSeekTo) is smaller than that start kv of next data block, it means the target key value has a very high possibility in the current data block (if not in current data block, then the start kv of next data block should be returned. +Indexing on the start key has some defects here+) and it shall NOT query the HFileBlockIndex in this case. On the contrary, if the target key value is bigger, then it shall query the HFileBlockIndex. This improvement shall help to reduce the hotness of HFileBlockIndex and avoid some unnecessary IdLock Contention or Index Block Cache lookup. This JIRA is to port the fix to HBase trunk, etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6062) preCheckAndPut/Delete() checks for READ when also a WRITE is performed
[ https://issues.apache.org/jira/browse/HBASE-6062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6062: - Resolution: Fixed Fix Version/s: (was: 0.96.0) Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed 0.92, 0.94 and trunk. Thanks for the patch Matteo. preCheckAndPut/Delete() checks for READ when also a WRITE is performed -- Key: HBASE-6062 URL: https://issues.apache.org/jira/browse/HBASE-6062 Project: HBase Issue Type: Sub-task Components: security Affects Versions: 0.92.1, 0.94.0, 0.96.0 Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Labels: acl, security Fix For: 0.92.2, 0.94.1 Attachments: HBASE-6062-0.92.patch, HBASE-6062-v0.patch, HBASE-6062-v1.patch preCheckAndPut() and preCheckAndDelete() checks for READ when they also want to WRITE... for me checking for WRITE permission is the right thing... what do you say about that? keep READ, replace with WRITE? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4891) HTable.ClientScanner needs to clone the Scan object
[ https://issues.apache.org/jira/browse/HBASE-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286139#comment-13286139 ] stack commented on HBASE-4891: -- Is this dup of HBASE-1774? HTable.ClientScanner needs to clone the Scan object --- Key: HBASE-4891 URL: https://issues.apache.org/jira/browse/HBASE-4891 Project: HBase Issue Type: Bug Affects Versions: 0.90.4 Reporter: Jean-Daniel Cryans Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.1 The ClientScanner can make some changes to the Scan object like setting a new start row when it gets an error, so if someone was reusing that object for a new scan thinking it would have the same properties, he/she would currently be wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-1989) HBaseAdmin (et al.) not accurate with Column vs. Column-Family usage
[ https://issues.apache.org/jira/browse/HBASE-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-1989: - Status: Open (was: Patch Available) Stale HBaseAdmin (et al.) not accurate with Column vs. Column-Family usage Key: HBASE-1989 URL: https://issues.apache.org/jira/browse/HBASE-1989 Project: HBase Issue Type: Bug Components: client Affects Versions: 0.90.1, 0.20.1 Reporter: Doug Meil Assignee: stack Priority: Minor Attachments: hbase1989.patch Consider the classes HBaseAdmin and HColumnDescriptor. HColumnDescriptor is really referring to a column family and not a column (i.e., family:qualifer). Likewise, in HBaseAdmin there is a method called addColumn that takes an HColumnDescriptor instance. I labeled this a bug in the sense that it produces conceptual confusion because there is a big difference between a column and column-family in HBase and these terms should be used consistently. The code works, though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-2042) ChecksumException generates thousands of open sockets
[
https://issues.apache.org/jira/browse/HBASE-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-2042:
-
Status: Open (was: Patch Available)
Stale
ChecksumException generates thousands of open sockets
-
Key: HBASE-2042
URL: https://issues.apache.org/jira/browse/HBASE-2042
Project: HBase
Issue Type: Bug
Reporter: stack
Priority: Blocker
Labels: moved_from_0_20_5
Attachments: hbase-2042.patch
Below is from Stefan Will:
{code}
I just ran into another case where a Regionserver wouldn't properly shut down
(this is on my development cluster, so not too critical). In this case, it is
also holding over 27000 datanode sockets (port 50010) in CLOSE_WAIT state. I
was actually using so many that the SSH daemon wouldn't let me log in to the
machine due to too many open file handles (I can probably figure out how to
increase that limit). So I shut down the Master and the other regionservers,
which might have been the cause for it to be in handleConnectionFailure().
The last few lines of the log were:
009-12-06 10:30:12,609 INFO
org.apache.hadoop.hbase.regionserver.HRegionServer: aborting server at:
10.1.20.144:60020 http://10.1.20.144:60020
- Hide quoted text -
2009-12-06 10:30:12,646 INFO org.apache.hadoop.hbase.regionserver.LogFlusher:
regionserver/10.1.20.144:60020.logFlusher exiting
2009-12-06 10:30:12,646 INFO
org.apache.hadoop.hbase.regionserver.HRegionServer$MajorCompactionChecker:
regionserver/10.1.20.144:60020.majorCompactionChecker exiting
2009-12-06 10:30:14,871 INFO org.apache.hadoop.hbase.Leases:
regionserver/10.1.20.144:60020.leaseChecker closing leases
2009-12-06 10:30:14,871 INFO org.apache.hadoop.hbase.Leases:
regionserver/10.1.20.144:60020.leaseChecker closed leases
2009-12-06 10:30:17,366 INFO
org.apache.hadoop.hbase.regionserver.HRegionServer: worker thread exiting
2009-12-06 10:30:17,366 INFO org.apache.zookeeper.ZooKeeper: Closing session:
0x2255b24f9f1003a
2009-12-06 10:30:17,366 INFO org.apache.zookeeper.ClientCnxn: Closing
ClientCnxn for session: 0x2255b24f9f1003a
2009-12-06 10:30:17,387 INFO org.apache.zookeeper.ClientCnxn: Exception while
closing send thread for session 0x2255b24f9f1003a : Read error rc = -1
java.nio.DirectByteBuffer[
pos=0 lim=4 cap=4]
2009-12-06 10:30:17,489 INFO org.apache.zookeeper.ClientCnxn: Disconnecting
ClientCnxn for session: 0x2255b24f9f1003a
2009-12-06 10:30:17,489 INFO org.apache.zookeeper.ZooKeeper: Session:
0x2255b24f9f1003a closed
2009-12-06 10:30:17,548 INFO org.apache.zookeeper.ClientCnxn: EventThread
shut down
2009-12-06 20:35:25,725 INFO
org.apache.hadoop.hbase.regionserver.HRegionServer: Starting shutdown thread.
And here is the stacktrace taken after I was able to log back into the
machine and send a kill to the process (at the last timestamp). It is now 15
minutes later, and the process is still running with no further log output.
Between midnight and 10:30, there are also over 6700 checksum errors in the
log, always with the same log file name:
org.apache.hadoop.fs.ChecksumException: Checksum error:
/blk_4234778497757442733:of:/hbase/post/1926133619/oldlogfile.log at 62521344
at
org.apache.hadoop.fs.FSInputChecker.verifySum(FSInputChecker.java:277)
at
org.apache.hadoop.fs.FSInputChecker.readChecksumChunk(FSInputChecker.java:241)
Here is the stack dump:
Exception in thread LeaseChecker java.lang.NullPointerException
at
org.apache.hadoop.ipc.Client$Connection.handleConnectionFailure(Client.java:351)
at org.apache.hadoop.ipc.Client$Connection.setupIOstreams(Client.java:313)
at org.apache.hadoop.ipc.Client$Connection.access$1700(Client.java:176)
at org.apache.hadoop.ipc.Client.getConnection(Client.java:859)
at org.apache.hadoop.ipc.Client.call(Client.java:719)
at org.apache.hadoop.ipc.RPC$Invoker.invoke(RPC.java:220)
at $Proxy1.renewLease(Unknown Source)
at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:82)
at
org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:59)
at $Proxy1.renewLease(Unknown Source)
at
org.apache.hadoop.hdfs.DFSClient$LeaseChecker.renew(DFSClient.java:1046)
at org.apache.hadoop.hdfs.DFSClient$LeaseChecker.run(DFSClient.java:1058)
at java.lang.Thread.run(Thread.java:619)
2009-12-06 20:43:32
Full thread dump Java HotSpot(TM) 64-Bit Server VM (14.0-b16 mixed mode):
Thread-28 prio=10 tid=0x539e5800 nid=0x742e in
[jira] [Updated] (HBASE-2214) Do HBASE-1996 -- setting size to return in scan rather than count of rows -- properly
[ https://issues.apache.org/jira/browse/HBASE-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-2214: - Resolution: Fixed Status: Resolved (was: Patch Available) This was committed a while back. Do HBASE-1996 -- setting size to return in scan rather than count of rows -- properly - Key: HBASE-2214 URL: https://issues.apache.org/jira/browse/HBASE-2214 Project: HBase Issue Type: New Feature Reporter: stack Assignee: Ferdy Galema Fix For: 0.96.0, 0.94.1 Attachments: HBASE-2214-0.94-v2.txt, HBASE-2214-0.94-v3.txt, HBASE-2214-0.94.txt, HBASE-2214-v4.txt, HBASE-2214-v5.txt, HBASE-2214-v6.txt, HBASE-2214-v7.txt, HBASE-2214_with_broken_TestShell.txt The notion that you set size rather than row count specifying how many rows a scanner should return in each cycle was raised over in hbase-1966. Its a good one making hbase regular though the data under it may vary. HBase-1966 was committed but the patch was constrained by the fact that it needed to not change RPC interface. This issue is about doing hbase-1966 for 0.21 in a clean, unconstrained way. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-2990) It's possible for regions to not be major compacted for more than hbase.hregion.majorcompaction
[ https://issues.apache.org/jira/browse/HBASE-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-2990: - Status: Open (was: Patch Available) Stale It's possible for regions to not be major compacted for more than hbase.hregion.majorcompaction --- Key: HBASE-2990 URL: https://issues.apache.org/jira/browse/HBASE-2990 Project: HBase Issue Type: Bug Affects Versions: 0.90.0 Reporter: Jean-Daniel Cryans Assignee: Jonathan Gray This is something I've seen here since we upgraded to 0.89 since Gets are now Scans, although I don't currently have any strong evidence that it wasn't happening in 0.20. I saw this when we began getting alerts on the frontend that some requests were taking more than 8 seconds to complete. Even getting a value could take more than 3 minutes in the shell. The first thing I did was major compacting the table that was slow and the problem went away immediately. Looking in the logs, it seems the compaction transformed 2 files of (total) 550MB into 5.2MB. Looking back in the logs for September, it appears that that table was never major compacted and was slowly growing everyday. Some more grepping around showed that quite a few regions were never major compacted. I'm still looking at the code, but the issue seems to be that the minor compactions are always happening on all store files more than once per day on certain regions, meaning that the oldest timestamp is always smaller than hbase.hregion.majorcompaction and major compactions are never triggered. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-3917) Separate the Avro schema definition file from the code
[ https://issues.apache.org/jira/browse/HBASE-3917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-3917: - Resolution: Won't Fix Status: Resolved (was: Patch Available) avro has been deprecated in trunk. We won't be fixing this issue. Separate the Avro schema definition file from the code -- Key: HBASE-3917 URL: https://issues.apache.org/jira/browse/HBASE-3917 Project: HBase Issue Type: Improvement Components: avro Affects Versions: 0.90.3 Reporter: Lars George Assignee: Alex Newman Priority: Trivial Labels: noob Fix For: 0.90.7 Attachments: 0001-HBASE-3917.-Separate-the-Avro-schema-definition-file.patch The Avro schema files are in the src/main/java path, but should be in /src/main/resources just like the Hbase.thrift is. Makes the separation the same and cleaner. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-4046) expose more statistics from HBase Master node
[ https://issues.apache.org/jira/browse/HBASE-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reassigned HBASE-4046: Assignee: Elliott Clark (was: nileema shingte) Anything to be recovered from this patch Elliott? expose more statistics from HBase Master node - Key: HBASE-4046 URL: https://issues.apache.org/jira/browse/HBASE-4046 Project: HBase Issue Type: Improvement Components: metrics Affects Versions: 0.92.0 Reporter: nileema shingte Assignee: Elliott Clark Priority: Minor Attachments: HBASE-4046.patch We can add the following statistics to the master. Some stats that can be added are: 1. number of logs split 2. size of logs split 3. number of region servers online 4. number of region servers opened 5. number of region servers expired -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6059) Replaying recovered edits would make deleted data exist again
[ https://issues.apache.org/jira/browse/HBASE-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6059: - Status: Open (was: Patch Available) Replaying recovered edits would make deleted data exist again - Key: HBASE-6059 URL: https://issues.apache.org/jira/browse/HBASE-6059 Project: HBase Issue Type: Bug Components: regionserver Reporter: chunhui shen Assignee: chunhui shen Fix For: 0.96.0 Attachments: 6059v6.txt, 6059v7.txt, 6059v7.txt, HBASE-6059-testcase.patch, HBASE-6059.patch, HBASE-6059v2.patch, HBASE-6059v3.patch, HBASE-6059v4.patch, HBASE-6059v5.patch When we replay recovered edits, we used the minSeqId of Store, It may cause deleted data appeared again. Let's see how it happens. Suppose the region with two families(cf1,cf2) 1.put one data to the region (put r1,cf1:q1,v1) 2.move the region from server A to server B. 3.delete the data put by step 1(delete r1) 4.flush this region. 5.make major compaction for this region 6.move the region from server B to server A. 7.Abort server A 8.After the region is online, we could get the deleted data(r1,cf1:q1,v1) (When we replay recovered edits, we used the minSeqId of Store, because cf2 has no store files, so its seqId is 0, so the edit log of put data will be replayed to the region) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6059) Replaying recovered edits would make deleted data exist again
[ https://issues.apache.org/jira/browse/HBASE-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6059: - Attachment: 6059v7.txt Replaying recovered edits would make deleted data exist again - Key: HBASE-6059 URL: https://issues.apache.org/jira/browse/HBASE-6059 Project: HBase Issue Type: Bug Components: regionserver Reporter: chunhui shen Assignee: chunhui shen Fix For: 0.96.0 Attachments: 6059v6.txt, 6059v7.txt, 6059v7.txt, HBASE-6059-testcase.patch, HBASE-6059.patch, HBASE-6059v2.patch, HBASE-6059v3.patch, HBASE-6059v4.patch, HBASE-6059v5.patch When we replay recovered edits, we used the minSeqId of Store, It may cause deleted data appeared again. Let's see how it happens. Suppose the region with two families(cf1,cf2) 1.put one data to the region (put r1,cf1:q1,v1) 2.move the region from server A to server B. 3.delete the data put by step 1(delete r1) 4.flush this region. 5.make major compaction for this region 6.move the region from server B to server A. 7.Abort server A 8.After the region is online, we could get the deleted data(r1,cf1:q1,v1) (When we replay recovered edits, we used the minSeqId of Store, because cf2 has no store files, so its seqId is 0, so the edit log of put data will be replayed to the region) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6059) Replaying recovered edits would make deleted data exist again
[ https://issues.apache.org/jira/browse/HBASE-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6059: - Status: Patch Available (was: Open) Replaying recovered edits would make deleted data exist again - Key: HBASE-6059 URL: https://issues.apache.org/jira/browse/HBASE-6059 Project: HBase Issue Type: Bug Components: regionserver Reporter: chunhui shen Assignee: chunhui shen Fix For: 0.96.0 Attachments: 6059v6.txt, 6059v7.txt, 6059v7.txt, HBASE-6059-testcase.patch, HBASE-6059.patch, HBASE-6059v2.patch, HBASE-6059v3.patch, HBASE-6059v4.patch, HBASE-6059v5.patch When we replay recovered edits, we used the minSeqId of Store, It may cause deleted data appeared again. Let's see how it happens. Suppose the region with two families(cf1,cf2) 1.put one data to the region (put r1,cf1:q1,v1) 2.move the region from server A to server B. 3.delete the data put by step 1(delete r1) 4.flush this region. 5.make major compaction for this region 6.move the region from server B to server A. 7.Abort server A 8.After the region is online, we could get the deleted data(r1,cf1:q1,v1) (When we replay recovered edits, we used the minSeqId of Store, because cf2 has no store files, so its seqId is 0, so the edit log of put data will be replayed to the region) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6046) Master retry on ZK session expiry causes inconsistent region assignments.
[ https://issues.apache.org/jira/browse/HBASE-6046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286169#comment-13286169 ] stack commented on HBASE-6046: -- What you think the fix is Ram? Master retry on ZK session expiry causes inconsistent region assignments. - Key: HBASE-6046 URL: https://issues.apache.org/jira/browse/HBASE-6046 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.92.1, 0.94.0 Reporter: Gopinathan A Assignee: ramkrishna.s.vasudevan Fix For: 0.92.2, 0.94.1 1 ZK Session timeout in the hmaster leads to bulk assignment though all the RSs are online. 2 While doing bulk assignment, if the master again goes down restart(or backup comes up) all the node created in the ZK will now be tried to reassign to the new RSs. This is leading to double assignment. we had 2800 regions, among this 1900 region got double assignment, taking the region count to 4700. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6087) Add hbase-common module
[ https://issues.apache.org/jira/browse/HBASE-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286172#comment-13286172 ] stack commented on HBASE-6087: -- Looks good. Waiting on hadoopqa. Add hbase-common module --- Key: HBASE-6087 URL: https://issues.apache.org/jira/browse/HBASE-6087 Project: HBase Issue Type: Bug Components: build Affects Versions: 0.96.0 Reporter: Jesse Yates Assignee: Jesse Yates Attachments: hbase-6087-v0.patch, hbase-6087-v1.patch, hbase-6087-v2.patch Add an hbase-common module so common/utility classes can be pulled up out of hbase-server. This is _not_ the moving of classes, just the general project setup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6087) Add hbase-common module
[ https://issues.apache.org/jira/browse/HBASE-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6087: - Status: Open (was: Patch Available) Add hbase-common module --- Key: HBASE-6087 URL: https://issues.apache.org/jira/browse/HBASE-6087 Project: HBase Issue Type: Bug Components: build Affects Versions: 0.96.0 Reporter: Jesse Yates Assignee: Jesse Yates Attachments: hbase-6087-v0.patch, hbase-6087-v1.patch, hbase-6087-v2.patch Add an hbase-common module so common/utility classes can be pulled up out of hbase-server. This is _not_ the moving of classes, just the general project setup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6085) SaslServer intermittently ignoring SaslClient's requests
[
https://issues.apache.org/jira/browse/HBASE-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286184#comment-13286184
]
stack commented on HBASE-6085:
--
A note of Andrew's on this issue:
{code}
Anything of note appear in the server side logs at DEBUG level? Have
you tried duplicating this in an all-localhost configuration? If it is
possible to reproduce in an all-localhost configuration, or on a
cluster not otherwise occupied, then we can turn on additional
SASL/GSSAPI level debugging that may shed light but will be quite
verbose.
{code}
SaslServer intermittently ignoring SaslClient's requests
Key: HBASE-6085
URL: https://issues.apache.org/jira/browse/HBASE-6085
Project: HBase
Issue Type: Bug
Components: security
Reporter: Himanshu Vashishtha
I often hit this problem where the client request is just ignored* by the
server.
The logs at the server doesn't reflect anything about the client, and then it
does process the request in the next trial.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5923) Cleanup checkAndXXX logic
[
https://issues.apache.org/jira/browse/HBASE-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286187#comment-13286187
]
stack commented on HBASE-5923:
--
@Lars Would suggest we make a simple standalone class w/ nought but enum in it,
the enums we need comparing. There are a few examples out there to be inspired
by:
http://docs.oracle.com/cd/E29578_01/CASAPI/cas-server-javadoc/com/endeca/itl/cas/api/ComparisonOperator.html
http://www.openoffice.org/api/docs/common/ref/com/sun/star/sheet/ConditionOperator.html
We'd then internally map to pb enum. Ugly but less ugly than exposing pb.
Cleanup checkAndXXX logic
-
Key: HBASE-5923
URL: https://issues.apache.org/jira/browse/HBASE-5923
Project: HBase
Issue Type: Improvement
Components: client, regionserver
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor
Fix For: 0.96.0, 0.94.1
Attachments: 5923-0.94.txt, 5923-trunk.txt
1. the checkAnd{Put|Delete} method that takes a CompareOP is not exposed via
HTable[Interface].
2. there is unnecessary duplicate code in the check{Put|Delete} code in
HRegionServer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-2110) Move to ivy broke our finding stylesheet (Tables don't have blue lines around them any more).
[ https://issues.apache.org/jira/browse/HBASE-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-2110. -- Resolution: Won't Fix As suggested by Alex, no longer applicable. Move to ivy broke our finding stylesheet (Tables don't have blue lines around them any more). - Key: HBASE-2110 URL: https://issues.apache.org/jira/browse/HBASE-2110 Project: HBase Issue Type: Bug Reporter: stack Labels: noob Move to ivy broke pulling in hbase.css from the static webapp; investigate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
