[jira] [Commented] (HBASE-14207) Region was hijacked and remained in transition when RS failed to open a region and later regionplan changed to new RS on retry
[
https://issues.apache.org/jira/browse/HBASE-14207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706331#comment-14706331
]
Pankaj Kumar commented on HBASE-14207:
--
Thanks [~stack].
> Region was hijacked and remained in transition when RS failed to open a
> region and later regionplan changed to new RS on retry
> --
>
> Key: HBASE-14207
> URL: https://issues.apache.org/jira/browse/HBASE-14207
> Project: HBase
> Issue Type: Bug
> Components: master
>Affects Versions: 0.98.6
>Reporter: Pankaj Kumar
>Assignee: Pankaj Kumar
>Priority: Critical
> Fix For: 0.98.15
>
> Attachments: HBASE-14207-0.98-V2.patch, HBASE-14207-0.98-V2.patch,
> HBASE-14207-0.98.patch
>
>
> On production environment, following events happened
> 1. Master is trying to assign a region to RS, but due to
> KeeperException$SessionExpiredException RS failed to open the region.
> In RS log, saw multiple WARN log related to
> KeeperException$SessionExpiredException
> > KeeperErrorCode = Session expired for
> /hbase/region-in-transition/08f1935d652e5dbdac09b423b8f9401b
> > Unable to get data of znode
> /hbase/region-in-transition/08f1935d652e5dbdac09b423b8f9401b
> 2. Master retried to assign the region to same RS, but RS again failed.
> 3. On second retry new plan formed and this time plan destination (RS) is
> different, so master send the request to new RS to open the region. But new
> RS failed to open the region as there was server mismatch in ZNODE than the
> expected current server name.
> Logs Snippet:
> {noformat}
> HM
> 2015-07-14 03:50:29,759 | INFO | master:T101PC03VM13:21300 | Processing
> 08f1935d652e5dbdac09b423b8f9401b in state: M_ZK_REGION_OFFLINE |
> org.apache.hadoop.hbase.master.AssignmentManager.processRegionsInTransition(AssignmentManager.java:644)
> 2015-07-14 03:50:29,759 | INFO | master:T101PC03VM13:21300 | Transitioned
> {08f1935d652e5dbdac09b423b8f9401b state=OFFLINE, ts=1436817029679,
> server=null} to {08f1935d652e5dbdac09b423b8f9401b state=PENDING_OPEN,
> ts=1436817029759, server=T101PC03VM13,21302,1436816690692} |
> org.apache.hadoop.hbase.master.RegionStates.updateRegionState(RegionStates.java:327)
> 2015-07-14 03:50:29,760 | INFO | master:T101PC03VM13:21300 | Processed
> region 08f1935d652e5dbdac09b423b8f9401b in state M_ZK_REGION_OFFLINE, on
> server: T101PC03VM13,21302,1436816690692 |
> org.apache.hadoop.hbase.master.AssignmentManager.processRegionsInTransition(AssignmentManager.java:768)
> 2015-07-14 03:50:29,800 | INFO |
> MASTER_SERVER_OPERATIONS-T101PC03VM13:21300-3 | Assigning
> INTER_CONCURRENCY_SETTING,,1436596137981.08f1935d652e5dbdac09b423b8f9401b. to
> T101PC03VM13,21302,1436816690692 |
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1983)
> 2015-07-14 03:50:29,801 | WARN |
> MASTER_SERVER_OPERATIONS-T101PC03VM13:21300-3 | Failed assignment of
> INTER_CONCURRENCY_SETTING,,1436596137981.08f1935d652e5dbdac09b423b8f9401b. to
> T101PC03VM13,21302,1436816690692, trying to assign elsewhere instead; try=1
> of 10 |
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:2077)
> 2015-07-14 03:50:29,802 | INFO |
> MASTER_SERVER_OPERATIONS-T101PC03VM13:21300-3 | Trying to re-assign
> INTER_CONCURRENCY_SETTING,,1436596137981.08f1935d652e5dbdac09b423b8f9401b. to
> the same failed server. |
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:2123)
> 2015-07-14 03:50:31,804 | INFO |
> MASTER_SERVER_OPERATIONS-T101PC03VM13:21300-3 | Assigning
> INTER_CONCURRENCY_SETTING,,1436596137981.08f1935d652e5dbdac09b423b8f9401b. to
> T101PC03VM13,21302,1436816690692 |
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1983)
> 2015-07-14 03:50:31,806 | WARN |
> MASTER_SERVER_OPERATIONS-T101PC03VM13:21300-3 | Failed assignment of
> INTER_CONCURRENCY_SETTING,,1436596137981.08f1935d652e5dbdac09b423b8f9401b. to
> T101PC03VM13,21302,1436816690692, trying to assign elsewhere instead; try=2
> of 10 |
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:2077)
> 2015-07-14 03:50:31,807 | INFO |
> MASTER_SERVER_OPERATIONS-T101PC03VM13:21300-3 | Transitioned
> {08f1935d652e5dbdac09b423b8f9401b state=PENDING_OPEN, ts=1436817031804,
> server=T101PC03VM13,21302,1436816690692} to {08f1935d652e5dbdac09b423b8f9401b
> state=OFFLINE, ts=1436817031807, server=T101PC03VM13,21302,1436816690692} |
> org.apache.hadoop.hbase.master.RegionStates.updateRegionState(RegionStates.java:327)
> 2015-07-14 03:50:31,807 | INFO |
> MASTER_SERVER_OPERATIONS-T101PC03VM13:21300-3 | Assigning
> INTER_CONC
[jira] [Commented] (HBASE-14274) Deadlock in region metrics on shutdown: MetricsRegionSourceImpl vs MetricsRegionAggregateSourceImpl
[
https://issues.apache.org/jira/browse/HBASE-14274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706358#comment-14706358
]
Hudson commented on HBASE-14274:
FAILURE: Integrated in HBase-1.3-IT #108 (See
[https://builds.apache.org/job/HBase-1.3-IT/108/])
HBASE-14274 Deadlock in region metrics on shutdown: MetricsRegionSourceImpl vs
MetricsRegionAggregateSourceImpl (stack: rev
f4ad31c8f91782e51e0bffdcd11c587a6c1dd3e9)
*
hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionAggregateSourceImpl.java
*
hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionSourceImpl.java
> Deadlock in region metrics on shutdown: MetricsRegionSourceImpl vs
> MetricsRegionAggregateSourceImpl
> ---
>
> Key: HBASE-14274
> URL: https://issues.apache.org/jira/browse/HBASE-14274
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Reporter: stack
>Assignee: Elliott Clark
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: 23612.stack, HBASE-14274-v1.patch, HBASE-14274.patch
>
>
> Looking into parent issue, got a hang locally of TestDistributedLogReplay.
> We have region closes here:
> {code}
> "RS_CLOSE_META-localhost:59610-0" prio=5 tid=0x7ff65c03f800 nid=0x54347
> waiting on condition [0x00011f7ac000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00075636d8c0> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
> at
> org.apache.hadoop.hbase.regionserver.MetricsRegionAggregateSourceImpl.deregister(MetricsRegionAggregateSourceImpl.java:78)
> at
> org.apache.hadoop.hbase.regionserver.MetricsRegionSourceImpl.close(MetricsRegionSourceImpl.java:120)
> at
> org.apache.hadoop.hbase.regionserver.MetricsRegion.close(MetricsRegion.java:41)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doClose(HRegion.java:1500)
> at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1344)
> - locked <0x0007ff878190> (a java.lang.Object)
> at
> org.apache.hadoop.hbase.regionserver.handler.CloseRegionHandler.process(CloseRegionHandler.java:102)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:103)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}
> They are trying to MetricsRegionAggregateSourceImpl.deregister. They want to
> get a write lock on this classes local ReentrantReadWriteLock while holding
> MetricsRegionSourceImpl's readWriteLock write lock.
> Then, elsewhere the JmxCacheBuster is running trying to get metrics with
> above locks held in reverse:
> {code}
> "HBase-Metrics2-1" daemon prio=5 tid=0x7ff65e14b000 nid=0x59a03 waiting
> on condition [0x000140ea5000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007cade1480> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:964)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1282)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:731)
> at
> org.apache.hadoop.hbase.regionserver.MetricsRegionSourceImpl.snapshot(MetricsRegionSourceImpl.java:193)
> at
> org.apache.hadoop.hbase.regionserver.MetricsRegionAggregateSourceImpl.getMetrics(MetricsRegionAggregateSourceImpl.java:115)
> at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getMetrics(MetricsSourceAdapter.java:195)
> at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.upda
[jira] [Commented] (HBASE-14260) don't build javadocs for hbase-protocol module
[
https://issues.apache.org/jira/browse/HBASE-14260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706357#comment-14706357
]
Hudson commented on HBASE-14260:
FAILURE: Integrated in HBase-1.3-IT #108 (See
[https://builds.apache.org/job/HBase-1.3-IT/108/])
HBASE-14260 skip javadoc generation for the hbase-protocol generated classes
(busbey: rev 2478d3f0e9522232a04b3b1e761e81bfa0d97b3f)
* hbase-protocol/pom.xml
> don't build javadocs for hbase-protocol module
> --
>
> Key: HBASE-14260
> URL: https://issues.apache.org/jira/browse/HBASE-14260
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 0.98.0, 1.0.0, 2.0.0, 1.1.0, 1.2.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0, 1.2.0, 1.1.2, 1.3.0, 0.98.15, 1.0.3
>
> Attachments: HBASE-14260.1.patch
>
>
> I'm not sure I have all the affected versions, but it seems that something is
> amiss in making our javadocs:
> {code}
> mvn -Papache-release -Prelease -DskipTests clean package
> ... SNIP ...
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache HBase ... SUCCESS [ 11.149
> s]
> [INFO] Apache HBase - Checkstyle .. SUCCESS [ 1.249
> s]
> [INFO] Apache HBase - Resource Bundle . SUCCESS [ 0.539
> s]
> [INFO] Apache HBase - Annotations . SUCCESS [ 4.438
> s]
> [INFO] Apache HBase - Protocol SUCCESS [10:15
> min]
> [INFO] Apache HBase - Common .. SUCCESS [ 48.465
> s]
> [INFO] Apache HBase - Procedure ... SUCCESS [ 14.375
> s]
> [INFO] Apache HBase - Client .. SUCCESS [ 45.187
> s]
> [INFO] Apache HBase - Hadoop Compatibility SUCCESS [ 6.998
> s]
> [INFO] Apache HBase - Hadoop Two Compatibility SUCCESS [ 14.891
> s]
> [INFO] Apache HBase - Prefix Tree . SUCCESS [ 14.214
> s]
> [INFO] Apache HBase - Server .. SUCCESS [02:01
> min]
> [INFO] Apache HBase - Testing Util SUCCESS [ 12.779
> s]
> [INFO] Apache HBase - Thrift .. SUCCESS [01:15
> min]
> [INFO] Apache HBase - Shell ... SUCCESS [ 6.649
> s]
> [INFO] Apache HBase - Integration Tests ... SUCCESS [ 6.429
> s]
> [INFO] Apache HBase - Examples SUCCESS [ 13.200
> s]
> [INFO] Apache HBase - Rest SUCCESS [ 27.831
> s]
> [INFO] Apache HBase - Assembly SUCCESS [ 19.400
> s]
> [INFO] Apache HBase - Shaded .. SUCCESS [ 0.419
> s]
> [INFO] Apache HBase - Shaded - Client . SUCCESS [ 23.707
> s]
> [INFO] Apache HBase - Shaded - Server . SUCCESS [ 43.654
> s]
> [INFO] Apache HBase - Spark ... SUCCESS [02:22
> min]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 21:13 min
> [INFO] Finished at: 2015-08-19T15:48:00-05:00
> [INFO] Final Memory: 181M/1513M
> [INFO]
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14265) we should forbid creating table using 'hbase' namespace except by superuser
[
https://issues.apache.org/jira/browse/HBASE-14265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706359#comment-14706359
]
Heng Chen commented on HBASE-14265:
---
[~apurtell] I reconsider this patch, and found this is not what i want.
As your suggestions, if security is active, everything is OK. And we has no
need to check table's NS in HMaster, because we can set normal users ACLs to
'hbase' Namespace.
But if we disable the security, user can still create table using 'hbase'
namespace.
IMO we should forbid this action.
> we should forbid creating table using 'hbase' namespace except by superuser
> ---
>
> Key: HBASE-14265
> URL: https://issues.apache.org/jira/browse/HBASE-14265
> Project: HBase
> Issue Type: Bug
>Reporter: Heng Chen
> Attachments: HBASE-14265.patch, HBASE-14265_v2.patch
>
>
> Now, there is no limit for users who can create table under 'hbase'
> NameSpace. I think it has some risk.
> Because we use {{TableName.systemTable}} to decide whether this table is
> System or not.
> But as code, {{TableName.systemTable}} will be true, if NS equals "hbase'
> {code}
> if (Bytes.equals(NamespaceDescriptor.SYSTEM_NAMESPACE_NAME, namespace)) {
> this.namespace = NamespaceDescriptor.SYSTEM_NAMESPACE_NAME;
> this.namespaceAsString =
> NamespaceDescriptor.SYSTEM_NAMESPACE_NAME_STR;
> this.systemTable = true;
> }
> {code}
>
> And we treat system table and normal table differently.
> For example, https://issues.apache.org/jira/browse/HBASE-14257 will flush
> fast if table belong to system table.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-14279) Race condition in ConcurrentIndex
Hiroshi Ikeda created HBASE-14279:
-
Summary: Race condition in ConcurrentIndex
Key: HBASE-14279
URL: https://issues.apache.org/jira/browse/HBASE-14279
Project: HBase
Issue Type: Bug
Reporter: Hiroshi Ikeda
Priority: Minor
{{ConcurrentIndex.put}} and {{remove}} are in race condition. It is possible to
remove a non-empty set, and to add a value to a removed set. Also
{{ConcurrentIndex.values}} is vague in sense that the returned set sometimes
trace the current state and sometimes doesn't.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14260) don't build javadocs for hbase-protocol module
[
https://issues.apache.org/jira/browse/HBASE-14260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706393#comment-14706393
]
Hudson commented on HBASE-14260:
ABORTED: Integrated in HBase-1.3 #123 (See
[https://builds.apache.org/job/HBase-1.3/123/])
HBASE-14260 skip javadoc generation for the hbase-protocol generated classes
(busbey: rev 2478d3f0e9522232a04b3b1e761e81bfa0d97b3f)
* hbase-protocol/pom.xml
> don't build javadocs for hbase-protocol module
> --
>
> Key: HBASE-14260
> URL: https://issues.apache.org/jira/browse/HBASE-14260
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 0.98.0, 1.0.0, 2.0.0, 1.1.0, 1.2.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0, 1.2.0, 1.1.2, 1.3.0, 0.98.15, 1.0.3
>
> Attachments: HBASE-14260.1.patch
>
>
> I'm not sure I have all the affected versions, but it seems that something is
> amiss in making our javadocs:
> {code}
> mvn -Papache-release -Prelease -DskipTests clean package
> ... SNIP ...
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache HBase ... SUCCESS [ 11.149
> s]
> [INFO] Apache HBase - Checkstyle .. SUCCESS [ 1.249
> s]
> [INFO] Apache HBase - Resource Bundle . SUCCESS [ 0.539
> s]
> [INFO] Apache HBase - Annotations . SUCCESS [ 4.438
> s]
> [INFO] Apache HBase - Protocol SUCCESS [10:15
> min]
> [INFO] Apache HBase - Common .. SUCCESS [ 48.465
> s]
> [INFO] Apache HBase - Procedure ... SUCCESS [ 14.375
> s]
> [INFO] Apache HBase - Client .. SUCCESS [ 45.187
> s]
> [INFO] Apache HBase - Hadoop Compatibility SUCCESS [ 6.998
> s]
> [INFO] Apache HBase - Hadoop Two Compatibility SUCCESS [ 14.891
> s]
> [INFO] Apache HBase - Prefix Tree . SUCCESS [ 14.214
> s]
> [INFO] Apache HBase - Server .. SUCCESS [02:01
> min]
> [INFO] Apache HBase - Testing Util SUCCESS [ 12.779
> s]
> [INFO] Apache HBase - Thrift .. SUCCESS [01:15
> min]
> [INFO] Apache HBase - Shell ... SUCCESS [ 6.649
> s]
> [INFO] Apache HBase - Integration Tests ... SUCCESS [ 6.429
> s]
> [INFO] Apache HBase - Examples SUCCESS [ 13.200
> s]
> [INFO] Apache HBase - Rest SUCCESS [ 27.831
> s]
> [INFO] Apache HBase - Assembly SUCCESS [ 19.400
> s]
> [INFO] Apache HBase - Shaded .. SUCCESS [ 0.419
> s]
> [INFO] Apache HBase - Shaded - Client . SUCCESS [ 23.707
> s]
> [INFO] Apache HBase - Shaded - Server . SUCCESS [ 43.654
> s]
> [INFO] Apache HBase - Spark ... SUCCESS [02:22
> min]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 21:13 min
> [INFO] Finished at: 2015-08-19T15:48:00-05:00
> [INFO] Final Memory: 181M/1513M
> [INFO]
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14279) Race condition in ConcurrentIndex
[
https://issues.apache.org/jira/browse/HBASE-14279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706430#comment-14706430
]
Heng Chen commented on HBASE-14279:
---
yeah... maybe we can replace {{ConcurrentMap> container;}} with
{{ConcurrentMap>> container;}}
{{Pair.getFirst()}} is Lock for current key. {{Pair.getSecond()}} is real set.
> Race condition in ConcurrentIndex
> -
>
> Key: HBASE-14279
> URL: https://issues.apache.org/jira/browse/HBASE-14279
> Project: HBase
> Issue Type: Bug
>Reporter: Hiroshi Ikeda
>Priority: Minor
>
> {{ConcurrentIndex.put}} and {{remove}} are in race condition. It is possible
> to remove a non-empty set, and to add a value to a removed set. Also
> {{ConcurrentIndex.values}} is vague in sense that the returned set sometimes
> trace the current state and sometimes doesn't.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14277) TestRegionServerHostname.testRegionServerHostname may fail at host with a case sensitive name
[ https://issues.apache.org/jira/browse/HBASE-14277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu Shaohui updated HBASE-14277: Affects Version/s: 2.0.0 Component/s: test > TestRegionServerHostname.testRegionServerHostname may fail at host with a > case sensitive name > - > > Key: HBASE-14277 > URL: https://issues.apache.org/jira/browse/HBASE-14277 > Project: HBase > Issue Type: Test > Components: test >Affects Versions: 2.0.0 >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-14277-v001.diff > > > After HBASE-13995, hostname will be converted to lower case in ServerName. It > may cause the test: TestRegionServerHostname.testRegionServerHostname failed > at host with a case sensitive name. > Just fix it in test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14277) TestRegionServerHostname.testRegionServerHostname may fail at host with a case sensitive name
[ https://issues.apache.org/jira/browse/HBASE-14277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706440#comment-14706440 ] Liu Shaohui commented on HBASE-14277: - [~tedyu] It seems that the CI build was not triggered automatically. Is there something wrong? Or How to start it manually? Thanks~ > TestRegionServerHostname.testRegionServerHostname may fail at host with a > case sensitive name > - > > Key: HBASE-14277 > URL: https://issues.apache.org/jira/browse/HBASE-14277 > Project: HBase > Issue Type: Test > Components: test >Affects Versions: 2.0.0 >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-14277-v001.diff > > > After HBASE-13995, hostname will be converted to lower case in ServerName. It > may cause the test: TestRegionServerHostname.testRegionServerHostname failed > at host with a case sensitive name. > Just fix it in test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14277) TestRegionServerHostname.testRegionServerHostname may fail at host with a case sensitive name
[ https://issues.apache.org/jira/browse/HBASE-14277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu Shaohui updated HBASE-14277: Attachment: HBASE-14277-v002.diff Rebase on master to trigger the CI build. > TestRegionServerHostname.testRegionServerHostname may fail at host with a > case sensitive name > - > > Key: HBASE-14277 > URL: https://issues.apache.org/jira/browse/HBASE-14277 > Project: HBase > Issue Type: Test > Components: test >Affects Versions: 2.0.0 >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-14277-v001.diff, HBASE-14277-v002.diff > > > After HBASE-13995, hostname will be converted to lower case in ServerName. It > may cause the test: TestRegionServerHostname.testRegionServerHostname failed > at host with a case sensitive name. > Just fix it in test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Liu Shaohui updated HBASE-14247:
Attachment: HBASE-14247-v002.diff
Fix some failed tests
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-14247-v001.diff, HBASE-14247-v002.diff
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706449#comment-14706449
]
Liu Shaohui commented on HBASE-14247:
-
[~stack] [~apurtell]
What's your suggestions about this change?
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-14247-v001.diff, HBASE-14247-v002.diff
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706451#comment-14706451
]
Jingcheng Du commented on HBASE-14227:
--
Thanks [~chenheng]!
Maybe too many details for a public client. Sorry for mislead in my previous
comments.
How about this?
{noformat}
/**
* The compaction types.
* {@code NORMAL} is for compaction in store files.
* {@code MOB} is for mob. If it is used the compaction of mob files is
triggered.
**/
{noformat}
[~anoopsamjohn], do you want to have a look and give some advice? Thanks.
> Fold special cased MOB APIs into existing APIs
> --
>
> Key: HBASE-14227
> URL: https://issues.apache.org/jira/browse/HBASE-14227
> Project: HBase
> Issue Type: Task
> Components: mob
>Affects Versions: 2.0.0
>Reporter: Andrew Purtell
>Assignee: Heng Chen
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-14227.patch, HBASE-14227_v1.patch,
> HBASE-14227_v2.patch, HBASE-14227_v3.patch
>
>
> There are a number of APIs that came in with MOB that are not new actions for
> HBase, simply new actions for a MOB implementation:
> - compactMob
> - compactMobs
> - majorCompactMob
> - majorCompactMobs
> - getMobCompactionState
> And in HBaseAdmin:
> - validateMobColumnFamily
> Remove these special cases from the Admin API where possible by folding them
> into existing APIs.
> We definitely don't need one method for a singleton and another for
> collections.
> Ideally we will not have any APIs named *Mob when finished, whether MOBs are
> in use on a table or not should be largely an internal detail. Exposing as
> schema option would be fine, this conforms to existing practice for other
> features.
> Marking critical because I think removing the *Mob special cased APIs should
> be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14260) don't build javadocs for hbase-protocol module
[
https://issues.apache.org/jira/browse/HBASE-14260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706470#comment-14706470
]
Hudson commented on HBASE-14260:
FAILURE: Integrated in HBase-1.2 #125 (See
[https://builds.apache.org/job/HBase-1.2/125/])
HBASE-14260 skip javadoc generation for the hbase-protocol generated classes
(busbey: rev 1fa33e89760110f19759308e74863d4f61866dc3)
* hbase-protocol/pom.xml
> don't build javadocs for hbase-protocol module
> --
>
> Key: HBASE-14260
> URL: https://issues.apache.org/jira/browse/HBASE-14260
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 0.98.0, 1.0.0, 2.0.0, 1.1.0, 1.2.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0, 1.2.0, 1.1.2, 1.3.0, 0.98.15, 1.0.3
>
> Attachments: HBASE-14260.1.patch
>
>
> I'm not sure I have all the affected versions, but it seems that something is
> amiss in making our javadocs:
> {code}
> mvn -Papache-release -Prelease -DskipTests clean package
> ... SNIP ...
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache HBase ... SUCCESS [ 11.149
> s]
> [INFO] Apache HBase - Checkstyle .. SUCCESS [ 1.249
> s]
> [INFO] Apache HBase - Resource Bundle . SUCCESS [ 0.539
> s]
> [INFO] Apache HBase - Annotations . SUCCESS [ 4.438
> s]
> [INFO] Apache HBase - Protocol SUCCESS [10:15
> min]
> [INFO] Apache HBase - Common .. SUCCESS [ 48.465
> s]
> [INFO] Apache HBase - Procedure ... SUCCESS [ 14.375
> s]
> [INFO] Apache HBase - Client .. SUCCESS [ 45.187
> s]
> [INFO] Apache HBase - Hadoop Compatibility SUCCESS [ 6.998
> s]
> [INFO] Apache HBase - Hadoop Two Compatibility SUCCESS [ 14.891
> s]
> [INFO] Apache HBase - Prefix Tree . SUCCESS [ 14.214
> s]
> [INFO] Apache HBase - Server .. SUCCESS [02:01
> min]
> [INFO] Apache HBase - Testing Util SUCCESS [ 12.779
> s]
> [INFO] Apache HBase - Thrift .. SUCCESS [01:15
> min]
> [INFO] Apache HBase - Shell ... SUCCESS [ 6.649
> s]
> [INFO] Apache HBase - Integration Tests ... SUCCESS [ 6.429
> s]
> [INFO] Apache HBase - Examples SUCCESS [ 13.200
> s]
> [INFO] Apache HBase - Rest SUCCESS [ 27.831
> s]
> [INFO] Apache HBase - Assembly SUCCESS [ 19.400
> s]
> [INFO] Apache HBase - Shaded .. SUCCESS [ 0.419
> s]
> [INFO] Apache HBase - Shaded - Client . SUCCESS [ 23.707
> s]
> [INFO] Apache HBase - Shaded - Server . SUCCESS [ 43.654
> s]
> [INFO] Apache HBase - Spark ... SUCCESS [02:22
> min]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 21:13 min
> [INFO] Finished at: 2015-08-19T15:48:00-05:00
> [INFO] Final Memory: 181M/1513M
> [INFO]
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13408) HBase In-Memory Memstore Compaction
[ https://issues.apache.org/jira/browse/HBASE-13408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706496#comment-14706496 ] Eshcar Hillel commented on HBASE-13408: --- Patch is updated on review board. 0.98-inmem means setting the cluster with the code of branch 0.98 and running an in-memory column family. > HBase In-Memory Memstore Compaction > --- > > Key: HBASE-13408 > URL: https://issues.apache.org/jira/browse/HBASE-13408 > Project: HBase > Issue Type: New Feature >Reporter: Eshcar Hillel > Attachments: HBASE-13408-trunk-v01.patch, > HBASE-13408-trunk-v02.patch, > HBaseIn-MemoryMemstoreCompactionDesignDocument-ver02.pdf, > HBaseIn-MemoryMemstoreCompactionDesignDocument.pdf, > InMemoryMemstoreCompactionEvaluationResults.pdf, > InMemoryMemstoreCompactionScansEvaluationResults.pdf > > > A store unit holds a column family in a region, where the memstore is its > in-memory component. The memstore absorbs all updates to the store; from time > to time these updates are flushed to a file on disk, where they are > compacted. Unlike disk components, the memstore is not compacted until it is > written to the filesystem and optionally to block-cache. This may result in > underutilization of the memory due to duplicate entries per row, for example, > when hot data is continuously updated. > Generally, the faster the data is accumulated in memory, more flushes are > triggered, the data sinks to disk more frequently, slowing down retrieval of > data, even if very recent. > In high-churn workloads, compacting the memstore can help maintain the data > in memory, and thereby speed up data retrieval. > We suggest a new compacted memstore with the following principles: > 1.The data is kept in memory for as long as possible > 2.Memstore data is either compacted or in process of being compacted > 3.Allow a panic mode, which may interrupt an in-progress compaction and > force a flush of part of the memstore. > We suggest applying this optimization only to in-memory column families. > A design document is attached. > This feature was previously discussed in HBASE-5311. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13996) Add write sniffing in canary
[ https://issues.apache.org/jira/browse/HBASE-13996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu Shaohui updated HBASE-13996: Attachment: HBASE-13996-v004.diff Fix the checkstyle errors > Add write sniffing in canary > > > Key: HBASE-13996 > URL: https://issues.apache.org/jira/browse/HBASE-13996 > Project: HBase > Issue Type: Improvement > Components: canary >Affects Versions: 0.98.13, 1.1.0.1 >Reporter: Liu Shaohui >Assignee: Liu Shaohui > Fix For: 2.0.0, 1.3.0, 0.98.15 > > Attachments: HBASE-13996-v001.diff, HBASE-13996-v002.diff, > HBASE-13996-v003.diff, HBASE-13996-v004.diff > > > Currently the canary tool only sniff the read operations, it's hard to > finding the problem in write path. > To support the write sniffing, we create a system table named '_canary_' in > the canary tool. And the tool will make sure that the region number is large > than the number of the regionserver and the regions will be distributed onto > all regionservers. > Periodically, the tool will put data to these regions to calculate the write > availability of HBase and send alerts if needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14274) Deadlock in region metrics on shutdown: MetricsRegionSourceImpl vs MetricsRegionAggregateSourceImpl
[
https://issues.apache.org/jira/browse/HBASE-14274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706539#comment-14706539
]
Hudson commented on HBASE-14274:
FAILURE: Integrated in HBase-TRUNK #6744 (See
[https://builds.apache.org/job/HBase-TRUNK/6744/])
HBASE-14274 Deadlock in region metrics on shutdown: MetricsRegionSourceImpl vs
MetricsRegionAggregateSourceImpl (stack: rev
bcef28eefaf192b0ad48c8011f98b8e944340da5)
*
hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionSourceImpl.java
*
hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionAggregateSourceImpl.java
> Deadlock in region metrics on shutdown: MetricsRegionSourceImpl vs
> MetricsRegionAggregateSourceImpl
> ---
>
> Key: HBASE-14274
> URL: https://issues.apache.org/jira/browse/HBASE-14274
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Reporter: stack
>Assignee: Elliott Clark
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: 23612.stack, HBASE-14274-v1.patch, HBASE-14274.patch
>
>
> Looking into parent issue, got a hang locally of TestDistributedLogReplay.
> We have region closes here:
> {code}
> "RS_CLOSE_META-localhost:59610-0" prio=5 tid=0x7ff65c03f800 nid=0x54347
> waiting on condition [0x00011f7ac000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00075636d8c0> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
> at
> org.apache.hadoop.hbase.regionserver.MetricsRegionAggregateSourceImpl.deregister(MetricsRegionAggregateSourceImpl.java:78)
> at
> org.apache.hadoop.hbase.regionserver.MetricsRegionSourceImpl.close(MetricsRegionSourceImpl.java:120)
> at
> org.apache.hadoop.hbase.regionserver.MetricsRegion.close(MetricsRegion.java:41)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doClose(HRegion.java:1500)
> at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1344)
> - locked <0x0007ff878190> (a java.lang.Object)
> at
> org.apache.hadoop.hbase.regionserver.handler.CloseRegionHandler.process(CloseRegionHandler.java:102)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:103)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}
> They are trying to MetricsRegionAggregateSourceImpl.deregister. They want to
> get a write lock on this classes local ReentrantReadWriteLock while holding
> MetricsRegionSourceImpl's readWriteLock write lock.
> Then, elsewhere the JmxCacheBuster is running trying to get metrics with
> above locks held in reverse:
> {code}
> "HBase-Metrics2-1" daemon prio=5 tid=0x7ff65e14b000 nid=0x59a03 waiting
> on condition [0x000140ea5000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007cade1480> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:964)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1282)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:731)
> at
> org.apache.hadoop.hbase.regionserver.MetricsRegionSourceImpl.snapshot(MetricsRegionSourceImpl.java:193)
> at
> org.apache.hadoop.hbase.regionserver.MetricsRegionAggregateSourceImpl.getMetrics(MetricsRegionAggregateSourceImpl.java:115)
> at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getMetrics(MetricsSourceAdapter.java:195)
> at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.upda
[jira] [Updated] (HBASE-14265) we should forbid creating table using 'hbase' namespace except by superuser
[
https://issues.apache.org/jira/browse/HBASE-14265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Heng Chen updated HBASE-14265:
--
Attachment: HBASE-14265_v3.patch
When security enabled, we can depend on ACLs to protect 'hbase' namespace, So
i update the patch, changes below:
* we only forbid creating table using 'hbase' namespace when security disabled
> we should forbid creating table using 'hbase' namespace except by superuser
> ---
>
> Key: HBASE-14265
> URL: https://issues.apache.org/jira/browse/HBASE-14265
> Project: HBase
> Issue Type: Bug
>Reporter: Heng Chen
> Attachments: HBASE-14265.patch, HBASE-14265_v2.patch,
> HBASE-14265_v3.patch
>
>
> Now, there is no limit for users who can create table under 'hbase'
> NameSpace. I think it has some risk.
> Because we use {{TableName.systemTable}} to decide whether this table is
> System or not.
> But as code, {{TableName.systemTable}} will be true, if NS equals "hbase'
> {code}
> if (Bytes.equals(NamespaceDescriptor.SYSTEM_NAMESPACE_NAME, namespace)) {
> this.namespace = NamespaceDescriptor.SYSTEM_NAMESPACE_NAME;
> this.namespaceAsString =
> NamespaceDescriptor.SYSTEM_NAMESPACE_NAME_STR;
> this.systemTable = true;
> }
> {code}
>
> And we treat system table and normal table differently.
> For example, https://issues.apache.org/jira/browse/HBASE-14257 will flush
> fast if table belong to system table.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14273) Rename MVCC to MVCC: From MultiVersionConsistencyControl to MultiVersionConcurrencyControl
[ https://issues.apache.org/jira/browse/HBASE-14273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706559#comment-14706559 ] Lars George commented on HBASE-14273: - What versions should we push this into? I'd suggest the unreleased major and minor only, i.e. 1.2 and 2.0 branches. I mean it does not hurt anyone else, and no one has really questioned it. It is internal too, so no API impact. Right? > Rename MVCC to MVCC: From MultiVersionConsistencyControl to > MultiVersionConcurrencyControl > -- > > Key: HBASE-14273 > URL: https://issues.apache.org/jira/browse/HBASE-14273 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: Lars Francke > Labels: beginner > Attachments: HBASE-14273.patch > > > [~larsgeorge] noticed that our MVCC class has Consistency as the first 'C' > when it should be 'Concurrency'. The issue that named this class, HBASE-4544 > talks about 'Concurrency' but then it went in as Consistency (Why has no one > noticed this before now? Thanks [~larsgeorge]) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-14280) Bulk Upload from HA cluster to remote HA hbase cluster fails
Ankit Singhal created HBASE-14280: - Summary: Bulk Upload from HA cluster to remote HA hbase cluster fails Key: HBASE-14280 URL: https://issues.apache.org/jira/browse/HBASE-14280 Project: HBase Issue Type: Bug Components: hadoop2, regionserver Affects Versions: 1.1.0.1 Reporter: Ankit Singhal Assignee: Ankit Singhal Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (HBASE-14280) Bulk Upload from HA cluster to remote HA hbase cluster fails
[ https://issues.apache.org/jira/browse/HBASE-14280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-14280 started by Ankit Singhal. - > Bulk Upload from HA cluster to remote HA hbase cluster fails > > > Key: HBASE-14280 > URL: https://issues.apache.org/jira/browse/HBASE-14280 > Project: HBase > Issue Type: Bug > Components: hadoop2, regionserver >Affects Versions: 1.1.0.1 >Reporter: Ankit Singhal >Assignee: Ankit Singhal >Priority: Minor > Labels: easyfix, patch > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14280) Bulk Upload from HA cluster to remote HA hbase cluster fails
[ https://issues.apache.org/jira/browse/HBASE-14280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated HBASE-14280: -- Release Note: It will be supported with Hadoop 2.6 with a launch of "internal.nameservices". (was: It will be supported Hadoop 2.6 with a launch of internal.nameservices.) Affects Version/s: 0.98.4 Status: Patch Available (was: In Progress) > Bulk Upload from HA cluster to remote HA hbase cluster fails > > > Key: HBASE-14280 > URL: https://issues.apache.org/jira/browse/HBASE-14280 > Project: HBase > Issue Type: Bug > Components: hadoop2, regionserver >Affects Versions: 1.1.0.1, 0.98.4 >Reporter: Ankit Singhal >Assignee: Ankit Singhal >Priority: Minor > Labels: easyfix, patch > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14280) Bulk Upload from HA cluster to remote HA hbase cluster fails
[ https://issues.apache.org/jira/browse/HBASE-14280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated HBASE-14280: -- Attachment: HBASE-14280_v1.0.patch > Bulk Upload from HA cluster to remote HA hbase cluster fails > > > Key: HBASE-14280 > URL: https://issues.apache.org/jira/browse/HBASE-14280 > Project: HBase > Issue Type: Bug > Components: hadoop2, regionserver >Affects Versions: 0.98.4, 1.1.0.1 >Reporter: Ankit Singhal >Assignee: Ankit Singhal >Priority: Minor > Labels: easyfix, patch > Attachments: HBASE-14280_v1.0.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14280) Bulk Upload from HA cluster to remote HA hbase cluster fails
[ https://issues.apache.org/jira/browse/HBASE-14280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated HBASE-14280: -- Description: Caused by: org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(java.io.IOException): java.io.IOException: Wrong FS: hdfs://ha-aggregation-nameservice1/hbase_upload/82c89692-6e78-46ef-bbea-c9e825318bfe/A/131358d641c69d6c34b803c187b0, expected: hdfs://ha-hbase-nameservice1 at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2113) at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:108) at org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:114) at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:94) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.IllegalArgumentException: Wrong FS: hdfs://ha-aggregation-nameservice1/hbase_upload/82c89692-6e78-46ef-bbea-c9e825318bfe/A/131358d641c69d6c34b803c187b0, expected: hdfs://ha-hbase-nameservice1 at org.apache.hadoop.fs.FileSystem.checkPath(FileSystem.java:645) at org.apache.hadoop.hdfs.DistributedFileSystem.getPathName(DistributedFileSystem.java:193) at org.apache.hadoop.hdfs.DistributedFileSystem.access$000(DistributedFileSystem.java:105) at org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:1136) at org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:1132) at org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81) at org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1132) at org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:414) at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1423) at org.apache.hadoop.hbase.regionserver.HRegionFileSystem.commitStoreFile(HRegionFileSystem.java:372) at org.apache.hadoop.hbase.regionserver.HRegionFileSystem.bulkLoadStoreFile(HRegionFileSystem.java:451) at org.apache.hadoop.hbase.regionserver.HStore.bulkLoadHFile(HStore.java:750) at org.apache.hadoop.hbase.regionserver.HRegion.bulkLoadHFiles(HRegion.java:4894) at org.apache.hadoop.hbase.regionserver.HRegion.bulkLoadHFiles(HRegion.java:4799) at org.apache.hadoop.hbase.regionserver.HRegionServer.bulkLoadHFile(HRegionServer.java:3377) at org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29996) at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2078) ... 4 more at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1498) at org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1684) at org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1737) at org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$BlockingStub.bulkLoadHFile(ClientProtos.java:29276) at org.apache.hadoop.hbase.protobuf.ProtobufUtil.bulkLoadHFile(ProtobufUtil.java:1548) ... 11 more > Bulk Upload from HA cluster to remote HA hbase cluster fails > > > Key: HBASE-14280 > URL: https://issues.apache.org/jira/browse/HBASE-14280 > Project: HBase > Issue Type: Bug > Components: hadoop2, regionserver >Affects Versions: 0.98.4, 1.1.0.1 >Reporter: Ankit Singhal >Assignee: Ankit Singhal >Priority: Minor > Labels: easyfix, patch > Attachments: HBASE-14280_v1.0.patch > > > Caused by: > org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(java.io.IOException): > java.io.IOException: Wrong FS: > hdfs://ha-aggregation-nameservice1/hbase_upload/82c89692-6e78-46ef-bbea-c9e825318bfe/A/131358d641c69d6c34b803c187b0, > expected: hdfs://ha-hbase-nameservice1 > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2113) > at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:108) > at > org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:114) > at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:94) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalArgumentException: Wrong FS: > hdfs://ha-aggregation-nameservice1/hbase_upload/82c89692-6e78-46ef-bbea-c9e825318bfe/A/131358d641c69d6c34b803c187b0, > expected: hdfs://ha-hbase-nameservice1 > at org.apache.hadoop.fs.FileSystem.checkPath(FileSystem.java:645) > at > org.apache.hadoop.hdfs.DistributedFileSystem.getPathName(DistributedFileSystem.java:193) > at > org.apache.hadoop.hdfs.DistributedFileSystem.access$000(DistributedFileSystem.ja
[jira] [Updated] (HBASE-14280) Bulk Upload from HA cluster to remote HA hbase cluster fails
[ https://issues.apache.org/jira/browse/HBASE-14280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated HBASE-14280: -- Release Note: It is supported with Hadoop 2.6 with a launch of "internal.nameservices". (was: It will be supported with Hadoop 2.6 with a launch of "internal.nameservices".) > Bulk Upload from HA cluster to remote HA hbase cluster fails > > > Key: HBASE-14280 > URL: https://issues.apache.org/jira/browse/HBASE-14280 > Project: HBase > Issue Type: Bug > Components: hadoop2, regionserver >Affects Versions: 0.98.4, 1.1.0.1 >Reporter: Ankit Singhal >Assignee: Ankit Singhal >Priority: Minor > Labels: easyfix, patch > Attachments: HBASE-14280_v1.0.patch > > > Caused by: > org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(java.io.IOException): > java.io.IOException: Wrong FS: > hdfs://ha-aggregation-nameservice1/hbase_upload/82c89692-6e78-46ef-bbea-c9e825318bfe/A/131358d641c69d6c34b803c187b0, > expected: hdfs://ha-hbase-nameservice1 > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2113) > at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:108) > at > org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:114) > at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:94) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalArgumentException: Wrong FS: > hdfs://ha-aggregation-nameservice1/hbase_upload/82c89692-6e78-46ef-bbea-c9e825318bfe/A/131358d641c69d6c34b803c187b0, > expected: hdfs://ha-hbase-nameservice1 > at org.apache.hadoop.fs.FileSystem.checkPath(FileSystem.java:645) > at > org.apache.hadoop.hdfs.DistributedFileSystem.getPathName(DistributedFileSystem.java:193) > at > org.apache.hadoop.hdfs.DistributedFileSystem.access$000(DistributedFileSystem.java:105) > at > org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:1136) > at > org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:1132) > at > org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81) > at > org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1132) > at > org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:414) > at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1423) > at > org.apache.hadoop.hbase.regionserver.HRegionFileSystem.commitStoreFile(HRegionFileSystem.java:372) > at > org.apache.hadoop.hbase.regionserver.HRegionFileSystem.bulkLoadStoreFile(HRegionFileSystem.java:451) > at > org.apache.hadoop.hbase.regionserver.HStore.bulkLoadHFile(HStore.java:750) > at > org.apache.hadoop.hbase.regionserver.HRegion.bulkLoadHFiles(HRegion.java:4894) > at > org.apache.hadoop.hbase.regionserver.HRegion.bulkLoadHFiles(HRegion.java:4799) > at > org.apache.hadoop.hbase.regionserver.HRegionServer.bulkLoadHFile(HRegionServer.java:3377) > at > org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29996) > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2078) > ... 4 more > at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1498) > at > org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1684) > at > org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1737) > at > org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$BlockingStub.bulkLoadHFile(ClientProtos.java:29276) > at > org.apache.hadoop.hbase.protobuf.ProtobufUtil.bulkLoadHFile(ProtobufUtil.java:1548) > ... 11 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14278) Fix NPE that is showing up since HBASE-14274 went in
[
https://issues.apache.org/jira/browse/HBASE-14278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706718#comment-14706718
]
Heng Chen commented on HBASE-14278:
---
I reproduce the problem locally. I think there is some risk in
{{JmxCacheBusterRunnable.run}},
{code}
if (DefaultMetricsSystem.instance() != null) {
DefaultMetricsSystem.instance().stop();
DefaultMetricsSystem.instance().start();
}
{code}
Maybe stop is not finished, but start is begin, so there are some conflicts.
So i add {{Thread.sleep(1000)}} after
{{DefaultMetricsSystem.instance().stop()}} and rerun testcase. NPE never
appear!
Hope it will help, and i will dig it too.
{code}
if (DefaultMetricsSystem.instance() != null) {
DefaultMetricsSystem.instance().stop();
Thread.sleep(1000);
DefaultMetricsSystem.instance().start();
}
{code}
> Fix NPE that is showing up since HBASE-14274 went in
>
>
> Key: HBASE-14278
> URL: https://issues.apache.org/jira/browse/HBASE-14278
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: stack
>
> Saw this in TestDistributedLogSplitting after HBASE-14274 was applied.
> {code}
> 119113 2015-08-20 15:31:10,704 WARN [HBase-Metrics2-1]
> impl.MetricsConfig(124): Cannot locate configuration: tried
> hadoop-metrics2-hbase.properties,hadoop-metrics2.properties
> 119114 2015-08-20 15:31:10,710 ERROR [HBase-Metrics2-1]
> lib.MethodMetric$2(118): Error invoking method getBlocksTotal
> 119115 java.lang.reflect.InvocationTargetException
> 119116 › at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source)
> 119117 › at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 119118 › at java.lang.reflect.Method.invoke(Method.java:606)
> 119119 › at
> org.apache.hadoop.metrics2.lib.MethodMetric$2.snapshot(MethodMetric.java:111)
> 119120 › at
> org.apache.hadoop.metrics2.lib.MethodMetric.snapshot(MethodMetric.java:144)
> 119121 › at
> org.apache.hadoop.metrics2.lib.MetricsRegistry.snapshot(MetricsRegistry.java:387)
> 119122 › at
> org.apache.hadoop.metrics2.lib.MetricsSourceBuilder$1.getMetrics(MetricsSourceBuilder.java:79)
> 119123 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getMetrics(MetricsSourceAdapter.java:195)
> 119124 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.updateJmxCache(MetricsSourceAdapter.java:172)
> 119125 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getMBeanInfo(MetricsSourceAdapter.java:151)
> 119126 › at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getNewMBeanClassName(DefaultMBeanServerInterceptor.java:333)
> 119127 › at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:319)
> 119128 › at
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> 119129 › at org.apache.hadoop.metrics2.util.MBeans.register(MBeans.java:57)
> 119130 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.startMBeans(MetricsSourceAdapter.java:221)
> 119131 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.start(MetricsSourceAdapter.java:96)
> 119132 › at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.registerSource(MetricsSystemImpl.java:245)
> 119133 › at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl$1.postStart(MetricsSystemImpl.java:229)
> 119134 › at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
> 119135 › at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 119136 › at java.lang.reflect.Method.invoke(Method.java:606)
> 119137 › at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl$3.invoke(MetricsSystemImpl.java:290)
> 119138 › at com.sun.proxy.$Proxy13.postStart(Unknown Source)
> 119139 › at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.start(MetricsSystemImpl.java:185)
> 119140 › at
> org.apache.hadoop.metrics2.impl.JmxCacheBuster$JmxCacheBusterRunnable.run(JmxCacheBuster.java:81)
> 119141 › at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> 119142 › at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 119143 › at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> 119144 › at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> 119145 › at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 119146 › at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 119147 › at java.lang.Thread.run(
[jira] [Commented] (HBASE-13329) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray
[ https://issues.apache.org/jira/browse/HBASE-13329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706821#comment-14706821 ] Michael Rose commented on HBASE-13329: -- In 1.x.x at least, this same change needs to be applied in both KeyValue.java (13329-v1.patch does this change) as well as CellComparator#getMinimumMidpointArray. Ran into this issue with HBase 1.0.0 (CDH5.4.0). It's unclear what originally caused the issue (after weeks of stable operation), but it would cause RSes to abort. At this point, no RS was able to open the region until I applied the patch from this issue as well as making the same change in CellComparator. With original patch applied even: slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing server shutdown org.apache.hadoop.hbase.DroppedSnapshotException: region: deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235. at org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243) at org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972) at org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935) at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833) at org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452) at org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413) at org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70) at org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NegativeArraySizeException at org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494) at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) at org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) at org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) at org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) at org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949) Was this an accidental omission? If so, should I open a new issue for this? > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray > > > Key: HBASE-13329 > URL: https://issues.apache.org/jira/browse/HBASE-13329 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.1 > Environment: linux-debian-jessie > ec2 - t2.micro instances >Reporter: Ruben Aguiar >Assignee: Lars Hofhansl >Priority: Critical > Fix For: 2.0.0, 1.0.2, 1.2.0, 1.1.2 > > Attachments: 13329-asserts.patch, 13329-v1.patch, 13329.txt, > HBASE-13329.test.00.branch-1.1.patch > > > While trying to benchmark my opentsdb cluster, I've created a script that > sends to hbase always the same value (in this case 1). After a few minutes, > the whole region server crashes and the region itself becomes impossible to > open again (cannot assign or unassign). After some investigation, what I saw > on the logs is that when a Memstore flush is called on a large region (128mb) > the process errors, killing the regionserver. On restart, replaying the edits > generates the same error, making the region unavailable. Tried to manually > unassign, assign or close_region. That didn't work because the code that > reads/replays it crashes. > From my investigation this seems to be an overflow issue. The logs show that > the function getMinimumMidpointArray tried to access index -32743 of an > array, extremely close to the minimum short value in Java. Upon investigation > of the source code, it seems an index short is used, being incremented as > long as the two vectors are the same, probably making it overflow on large > vectors with equal data. Changing it to int should solve the problem. > Here follows the hadoop logs of when the regionserver went down. Any help is > appreciated. Any other information you need please do tell me: > 2015-03-24 18:00:56,187 INFO [regionserver//10.2.0.73:16020.logRoller] > wal.FSHLog: Rolled WAL > /hbase/WALs/10.2.0.73,16020,1427216382590/10.2.0.73%2C16020%2C1427216382590.default.1427220018516 > with entries=143, filesize=134.70 MB; new WAL > /hbase/WALs/10.2.0.73,16020,1427216382590/10.2.0.73%2C16020%2C1427216382590.default.1427220056140 > 2015-03-24 18:00:56,188 INFO [regionserver//10.2.0.73:16020.logRoller] > wal.
[jira] [Commented] (HBASE-14269) FuzzyRowFilter omits certain rows when multiple fuzzy key exist
[ https://issues.apache.org/jira/browse/HBASE-14269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706835#comment-14706835 ] hongbin ma commented on HBASE-14269: Hi, When I compared the performance of differnt versions of FuzzyRowFilter I'm surprised that they exhibit no significant performance difference at all. The three versions that I compared are: 1. HBASE-13641: this is the last change before HBASE-13761's optimization 2. HBASE-13761: this is where the RowTracker optimization is introduced 3. HBASE-14269: this is where we fixed the bug in HBASE-13761 I modified the synthetic data settings in TestFuzzyRowFilterEndToEnd to make it more evenly distributed(see my latest patch). And here're the results for running testEndToEnd on three version of FuzzyRowFilter respectively: || ||HBASE-13641||HBASE-13761||HBASE-14269|| | runTest1's first run|138ms|130ms|133ms| | runTest1's second run|62ms|65ms|63ms| | runTest2's first run|183ms|94ms before assertion error|194ms| | runTest2's second run|53ms|N/A skipped because error|53ms| All of the three versions will succeed in runTest1, however HBASE-13761 will fail due to the bug we reported in this issue.(It will return incomplete result ret). As we can see there's no significant difference between them. It is reported in HBASE-13761 that its optimization has boost the performance a lot, however we guess it might be fast due to incomplete result set. Fuzzy filter is nothing magic, when it works it follows the pattern: (get row)(get hint)...(get row)(get hint) The RowTracker optimization in HBASE-13761 is merely optimizing the "get hint" part, and it remain doubt whether "get hint" part is the real bottleneck. If my benchmark based on minicluster is not convincing enough, please point out why, and show us another re-produceable benchmark. For now my conclusion would be: HBASE-13761 did not optimize FuzzyRowFilter that much, we should think about reverting the FuzzyRowFilter to original version, or simply merge the patch in this issue. (No significant difference in terms of performance) > FuzzyRowFilter omits certain rows when multiple fuzzy key exist > --- > > Key: HBASE-14269 > URL: https://issues.apache.org/jira/browse/HBASE-14269 > Project: HBase > Issue Type: Bug > Components: Filters >Reporter: hongbin ma >Assignee: hongbin ma > Attachments: HBASE-14269-v1.patch, HBASE-14269.patch > > > https://issues.apache.org/jira/browse/HBASE-13761 introduced a RowTracker in > FuzzyRowFilter to avoid performing getNextForFuzzyRule() for each fuzzy key > on each getNextCellHint() by maintaining a list of possible row matches for > each fuzzy key. The implementation assumes that the prepared rows will be > matched one by one, so it removes the first row in the list as soon as it is > used. However, this approach may lead to omitting rows in some cases: > Consider a case where we have two fuzzy keys: > 1?1 > 2?2 > and the data is like: > 000 > 111 > 112 > 121 > 122 > 211 > 212 > when the first row 000 fails to match, RowTracker will update possible row > matches with cell 000 and fuzzy keys 1?1,2?2. This will populate RowTracker > with 101 and 202. Then 101 is popped out of RowTracker, hint the scanner to > go to row 101. The scanner will get 111 and find it is a match, and continued > to find that 112 is not a match, getNextCellHint will be called again. Then > comes the bug: Row 101 has been removed out of RowTracker, so RowTracker will > jump to 202. As you see row 121 will be omitted, but it is actually a match > for fuzzy key 1?1. > I will illustrate the bug by adding a new test case in > TestFuzzyRowFilterEndToEnd. Also I will provide the bug fix in my patch. The > idea of the new solution is to maintain a priority queue for all the possible > match rows for each fuzzy key, and whenever getNextCellHint is called, the > elements in the queue that are smaller than the parameter currentCell will be > updated(and re-insert into the queue). The head of queue will always be the > "Next cell hint". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13329) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray
[ https://issues.apache.org/jira/browse/HBASE-13329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706836#comment-14706836 ] Sean Busbey commented on HBASE-13329: - looks like it. Please open a new issue, since this one has been in a release already. > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray > > > Key: HBASE-13329 > URL: https://issues.apache.org/jira/browse/HBASE-13329 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.1 > Environment: linux-debian-jessie > ec2 - t2.micro instances >Reporter: Ruben Aguiar >Assignee: Lars Hofhansl >Priority: Critical > Fix For: 2.0.0, 1.0.2, 1.2.0, 1.1.2 > > Attachments: 13329-asserts.patch, 13329-v1.patch, 13329.txt, > HBASE-13329.test.00.branch-1.1.patch > > > While trying to benchmark my opentsdb cluster, I've created a script that > sends to hbase always the same value (in this case 1). After a few minutes, > the whole region server crashes and the region itself becomes impossible to > open again (cannot assign or unassign). After some investigation, what I saw > on the logs is that when a Memstore flush is called on a large region (128mb) > the process errors, killing the regionserver. On restart, replaying the edits > generates the same error, making the region unavailable. Tried to manually > unassign, assign or close_region. That didn't work because the code that > reads/replays it crashes. > From my investigation this seems to be an overflow issue. The logs show that > the function getMinimumMidpointArray tried to access index -32743 of an > array, extremely close to the minimum short value in Java. Upon investigation > of the source code, it seems an index short is used, being incremented as > long as the two vectors are the same, probably making it overflow on large > vectors with equal data. Changing it to int should solve the problem. > Here follows the hadoop logs of when the regionserver went down. Any help is > appreciated. Any other information you need please do tell me: > 2015-03-24 18:00:56,187 INFO [regionserver//10.2.0.73:16020.logRoller] > wal.FSHLog: Rolled WAL > /hbase/WALs/10.2.0.73,16020,1427216382590/10.2.0.73%2C16020%2C1427216382590.default.1427220018516 > with entries=143, filesize=134.70 MB; new WAL > /hbase/WALs/10.2.0.73,16020,1427216382590/10.2.0.73%2C16020%2C1427216382590.default.1427220056140 > 2015-03-24 18:00:56,188 INFO [regionserver//10.2.0.73:16020.logRoller] > wal.FSHLog: Archiving > hdfs://10.2.0.74:8020/hbase/WALs/10.2.0.73,16020,1427216382590/10.2.0.73%2C16020%2C1427216382590.default.1427219987709 > to > hdfs://10.2.0.74:8020/hbase/oldWALs/10.2.0.73%2C16020%2C1427216382590.default.1427219987709 > 2015-03-24 18:04:35,722 INFO [MemStoreFlusher.0] regionserver.HRegion: > Started memstore flush for > tsdb,,1427133969325.52bc1994da0fea97563a4a656a58bec2., current region > memstore size 128.04 MB > 2015-03-24 18:04:36,154 FATAL [MemStoreFlusher.0] regionserver.HRegionServer: > ABORTING region server 10.2.0.73,16020,1427216382590: Replay of WAL required. > Forcing server shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > tsdb,,1427133969325.52bc1994da0fea97563a4a656a58bec2. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1999) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1770) > at > org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1702) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:445) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:407) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:69) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:225) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.ArrayIndexOutOfBoundsException: -32743 > at > org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:478) > at > org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV3.append(HFileWriterV3.java:87) > at > org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:932
[jira] [Commented] (HBASE-14269) FuzzyRowFilter omits certain rows when multiple fuzzy key exist
[ https://issues.apache.org/jira/browse/HBASE-14269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706837#comment-14706837 ] hongbin ma commented on HBASE-14269: Hi, When I compared the performance of differnt versions of FuzzyRowFilter I'm surprised that they exhibit no significant performance difference at all. The three versions that I compared are: 1. HBASE-13641: this is the last change before HBASE-13761's optimization 2. HBASE-13761: this is where the RowTracker optimization is introduced 3. HBASE-14269: this is where we fixed the bug in HBASE-13761 I modified the synthetic data settings in TestFuzzyRowFilterEndToEnd to make it more evenly distributed(see my latest patch). And here're the results for running testEndToEnd on three version of FuzzyRowFilter respectively: || ||HBASE-13641||HBASE-13761||HBASE-14269|| | runTest1's first run|138ms|130ms|133ms| | runTest1's second run|62ms|65ms|63ms| | runTest2's first run|183ms|94ms before assertion error|194ms| | runTest2's second run|53ms|N/A skipped because error|53ms| All of the three versions will succeed in runTest1, however HBASE-13761 will fail due to the bug we reported in this issue.(It will return incomplete result ret). As we can see there's no significant difference between them. It is reported in HBASE-13761 that its optimization has boost the performance a lot, however we guess it might be fast due to incomplete result set. Fuzzy filter is nothing magic, when it works it follows the pattern: (get row)(get hint)...(get row)(get hint) The RowTracker optimization in HBASE-13761 is merely optimizing the "get hint" part, and it remain doubt whether "get hint" part is the real bottleneck. If my benchmark based on minicluster is not convincing enough, please point out why, and show us another re-produceable benchmark. For now my conclusion would be: HBASE-13761 did not optimize FuzzyRowFilter that much, we should think about reverting the FuzzyRowFilter to original version, or simply merge the patch in this issue. (No significant difference in terms of performance) > FuzzyRowFilter omits certain rows when multiple fuzzy key exist > --- > > Key: HBASE-14269 > URL: https://issues.apache.org/jira/browse/HBASE-14269 > Project: HBase > Issue Type: Bug > Components: Filters >Reporter: hongbin ma >Assignee: hongbin ma > Attachments: HBASE-14269-v1.patch, HBASE-14269.patch > > > https://issues.apache.org/jira/browse/HBASE-13761 introduced a RowTracker in > FuzzyRowFilter to avoid performing getNextForFuzzyRule() for each fuzzy key > on each getNextCellHint() by maintaining a list of possible row matches for > each fuzzy key. The implementation assumes that the prepared rows will be > matched one by one, so it removes the first row in the list as soon as it is > used. However, this approach may lead to omitting rows in some cases: > Consider a case where we have two fuzzy keys: > 1?1 > 2?2 > and the data is like: > 000 > 111 > 112 > 121 > 122 > 211 > 212 > when the first row 000 fails to match, RowTracker will update possible row > matches with cell 000 and fuzzy keys 1?1,2?2. This will populate RowTracker > with 101 and 202. Then 101 is popped out of RowTracker, hint the scanner to > go to row 101. The scanner will get 111 and find it is a match, and continued > to find that 112 is not a match, getNextCellHint will be called again. Then > comes the bug: Row 101 has been removed out of RowTracker, so RowTracker will > jump to 202. As you see row 121 will be omitted, but it is actually a match > for fuzzy key 1?1. > I will illustrate the bug by adding a new test case in > TestFuzzyRowFilterEndToEnd. Also I will provide the bug fix in my patch. The > idea of the new solution is to maintain a priority queue for all the possible > match rows for each fuzzy key, and whenever getNextCellHint is called, the > elements in the queue that are smaller than the parameter currentCell will be > updated(and re-insert into the queue). The head of queue will always be the > "Next cell hint". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14269) FuzzyRowFilter omits certain rows when multiple fuzzy key exist
[ https://issues.apache.org/jira/browse/HBASE-14269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hongbin ma updated HBASE-14269: --- Attachment: HBASE-14269-v2.patch > FuzzyRowFilter omits certain rows when multiple fuzzy key exist > --- > > Key: HBASE-14269 > URL: https://issues.apache.org/jira/browse/HBASE-14269 > Project: HBase > Issue Type: Bug > Components: Filters >Reporter: hongbin ma >Assignee: hongbin ma > Attachments: HBASE-14269-v1.patch, HBASE-14269-v2.patch, > HBASE-14269.patch > > > https://issues.apache.org/jira/browse/HBASE-13761 introduced a RowTracker in > FuzzyRowFilter to avoid performing getNextForFuzzyRule() for each fuzzy key > on each getNextCellHint() by maintaining a list of possible row matches for > each fuzzy key. The implementation assumes that the prepared rows will be > matched one by one, so it removes the first row in the list as soon as it is > used. However, this approach may lead to omitting rows in some cases: > Consider a case where we have two fuzzy keys: > 1?1 > 2?2 > and the data is like: > 000 > 111 > 112 > 121 > 122 > 211 > 212 > when the first row 000 fails to match, RowTracker will update possible row > matches with cell 000 and fuzzy keys 1?1,2?2. This will populate RowTracker > with 101 and 202. Then 101 is popped out of RowTracker, hint the scanner to > go to row 101. The scanner will get 111 and find it is a match, and continued > to find that 112 is not a match, getNextCellHint will be called again. Then > comes the bug: Row 101 has been removed out of RowTracker, so RowTracker will > jump to 202. As you see row 121 will be omitted, but it is actually a match > for fuzzy key 1?1. > I will illustrate the bug by adding a new test case in > TestFuzzyRowFilterEndToEnd. Also I will provide the bug fix in my patch. The > idea of the new solution is to maintain a priority queue for all the possible > match rows for each fuzzy key, and whenever getNextCellHint is called, the > elements in the queue that are smaller than the parameter currentCell will be > updated(and re-insert into the queue). The head of queue will always be the > "Next cell hint". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14268) Improve KeyLocker
[
https://issues.apache.org/jira/browse/HBASE-14268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiroshi Ikeda updated HBASE-14268:
--
Attachment: HBASE-14268-V3.patch
Added a revised patch.
Refactored; Extracted the logic around handling weak references to a new class
{{WeakObjectPool}}.
The similar class {{IdLock}} can be rewritten with {{WeakObjectPool}}, and its
variant class using {{ReadWriteLock}} instead of {{Lock}} can be easily created
if needed, I guess :-)
> Improve KeyLocker
> -
>
> Key: HBASE-14268
> URL: https://issues.apache.org/jira/browse/HBASE-14268
> Project: HBase
> Issue Type: Improvement
> Components: util
>Reporter: Hiroshi Ikeda
>Assignee: Hiroshi Ikeda
>Priority: Minor
> Attachments: HBASE-14268-V2.patch, HBASE-14268-V3.patch,
> HBASE-14268.patch, KeyLockerPerformance.java
>
>
> 1. In the implementation of {{KeyLocker}} it uses atomic variables inside a
> synchronized block, which doesn't make sense. Moreover, logic inside the
> synchronized block is not trivial so that it makes less performance in heavy
> multi-threaded environment.
> 2. {{KeyLocker}} gives an instance of {{RentrantLock}} which is already
> locked, but it doesn't follow the contract of {{ReentrantLock}} because you
> are not allowed to freely invoke lock/unlock methods under that contract.
> That introduces a potential risk; Whenever you see a variable of the type
> {{RentrantLock}}, you should pay attention to what the included instance is
> coming from.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-14281) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2
Michael Rose created HBASE-14281: Summary: ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2 Key: HBASE-14281 URL: https://issues.apache.org/jira/browse/HBASE-14281 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 1.0.2, 1.0.1, 1.0.0 Reporter: Michael Rose Follow-on issue for HBASE-13329: CellComparator#getMinimumMidpointArray seems to have had a necessary change omitted and the patch only covered one of the two places diffIdx could overflow the short. For some background, we ran into the HBASE-13329 issue where a flush would cause a regionserver abort. After abort, the region in question would almost indefinitely sit in the FAILED_OPEN state. Applying the patch from HBASE-13329 didn't solve the issue, but I noticed a comment in that issue which applied the same change in CellComparator#getMinimumMidpointArray, but the change was omitted from the attached patch. RS abort for reference: slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing server shutdown org.apache.hadoop.hbase.DroppedSnapshotException: region: deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235. at org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243) at org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972) at org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935) at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833) at org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452) at org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413) at org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70) at org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NegativeArraySizeException at org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494) at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) at org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) at org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) at org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) at org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706853#comment-14706853
]
Dave Latham commented on HBASE-14247:
-
One concern with this change is that the OldLogCleaner as it is implemented
will now have to run through the cleaner checks for every region's subdirectory
instead of doing them all in one batch. It will likely make the cleaner chore
much slower and may not be able to keep up for large clusters.
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-14247-v001.diff, HBASE-14247-v002.diff
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14269) FuzzyRowFilter omits certain rows when multiple fuzzy key exist
[ https://issues.apache.org/jira/browse/HBASE-14269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706896#comment-14706896 ] Ted Yu commented on HBASE-14269: If more time is needed to arrive at a benchmark that everybody agrees, we should revert HBASE-13761. Otherwise we can go with the patch in this issue. > FuzzyRowFilter omits certain rows when multiple fuzzy key exist > --- > > Key: HBASE-14269 > URL: https://issues.apache.org/jira/browse/HBASE-14269 > Project: HBase > Issue Type: Bug > Components: Filters >Reporter: hongbin ma >Assignee: hongbin ma > Attachments: HBASE-14269-v1.patch, HBASE-14269-v2.patch, > HBASE-14269.patch > > > https://issues.apache.org/jira/browse/HBASE-13761 introduced a RowTracker in > FuzzyRowFilter to avoid performing getNextForFuzzyRule() for each fuzzy key > on each getNextCellHint() by maintaining a list of possible row matches for > each fuzzy key. The implementation assumes that the prepared rows will be > matched one by one, so it removes the first row in the list as soon as it is > used. However, this approach may lead to omitting rows in some cases: > Consider a case where we have two fuzzy keys: > 1?1 > 2?2 > and the data is like: > 000 > 111 > 112 > 121 > 122 > 211 > 212 > when the first row 000 fails to match, RowTracker will update possible row > matches with cell 000 and fuzzy keys 1?1,2?2. This will populate RowTracker > with 101 and 202. Then 101 is popped out of RowTracker, hint the scanner to > go to row 101. The scanner will get 111 and find it is a match, and continued > to find that 112 is not a match, getNextCellHint will be called again. Then > comes the bug: Row 101 has been removed out of RowTracker, so RowTracker will > jump to 202. As you see row 121 will be omitted, but it is actually a match > for fuzzy key 1?1. > I will illustrate the bug by adding a new test case in > TestFuzzyRowFilterEndToEnd. Also I will provide the bug fix in my patch. The > idea of the new solution is to maintain a priority queue for all the possible > match rows for each fuzzy key, and whenever getNextCellHint is called, the > elements in the queue that are smaller than the parameter currentCell will be > updated(and re-insert into the queue). The head of queue will always be the > "Next cell hint". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706859#comment-14706859
]
Dave Latham commented on HBASE-14247:
-
Oops, I meant to say every *region server's* subdirectory (instead of every
*region's* subdirectory).
This may be able to be mitigated by batching up cleaning checks across
directories.
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-14247-v001.diff, HBASE-14247-v002.diff
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14281) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2
[ https://issues.apache.org/jira/browse/HBASE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706911#comment-14706911 ] Sean Busbey commented on HBASE-14281: - thanks for filing this Michael. can you post up your additional fixes as a patch here? > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, > part 2 > > > Key: HBASE-14281 > URL: https://issues.apache.org/jira/browse/HBASE-14281 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.0, 1.0.1, 1.0.2 >Reporter: Michael Rose > > Follow-on issue for HBASE-13329: CellComparator#getMinimumMidpointArray seems > to have had a necessary change omitted and the patch only covered one of the > two places diffIdx could overflow the short. > For some background, we ran into the HBASE-13329 issue where a flush would > cause a regionserver abort. After abort, the region in question would almost > indefinitely sit in the FAILED_OPEN state. Applying the patch from > HBASE-13329 didn't solve the issue, but I noticed a comment in that issue > which applied the same change in CellComparator#getMinimumMidpointArray, but > the change was omitted from the attached patch. > RS abort for reference: > slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing > server shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935) > at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NegativeArraySizeException > at > org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494) > at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) > at > org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14281) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2
[ https://issues.apache.org/jira/browse/HBASE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706933#comment-14706933 ] Michael Rose commented on HBASE-14281: -- Patch submitted, has no supporting test cases yet. I'll look at what HBASE-13329 had and try to replicate it. > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, > part 2 > > > Key: HBASE-14281 > URL: https://issues.apache.org/jira/browse/HBASE-14281 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.0, 1.0.1, 1.0.2 >Reporter: Michael Rose > Attachments: 14281-v1.patch > > > Follow-on issue for HBASE-13329: CellComparator#getMinimumMidpointArray seems > to have had a necessary change omitted and the patch only covered one of the > two places diffIdx could overflow the short. > For some background, we ran into the HBASE-13329 issue where a flush would > cause a regionserver abort. After abort, the region in question would almost > indefinitely sit in the FAILED_OPEN state. Applying the patch from > HBASE-13329 didn't solve the issue, but I noticed a comment in that issue > which applied the same change in CellComparator#getMinimumMidpointArray, but > the change was omitted from the attached patch. > RS abort for reference: > slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing > server shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935) > at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NegativeArraySizeException > at > org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494) > at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) > at > org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14281) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2
[ https://issues.apache.org/jira/browse/HBASE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Rose updated HBASE-14281: - Attachment: 14281-v1.patch > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, > part 2 > > > Key: HBASE-14281 > URL: https://issues.apache.org/jira/browse/HBASE-14281 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.0, 1.0.1, 1.0.2 >Reporter: Michael Rose > Attachments: 14281-v1.patch > > > Follow-on issue for HBASE-13329: CellComparator#getMinimumMidpointArray seems > to have had a necessary change omitted and the patch only covered one of the > two places diffIdx could overflow the short. > For some background, we ran into the HBASE-13329 issue where a flush would > cause a regionserver abort. After abort, the region in question would almost > indefinitely sit in the FAILED_OPEN state. Applying the patch from > HBASE-13329 didn't solve the issue, but I noticed a comment in that issue > which applied the same change in CellComparator#getMinimumMidpointArray, but > the change was omitted from the attached patch. > RS abort for reference: > slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing > server shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935) > at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NegativeArraySizeException > at > org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494) > at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) > at > org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14250) branch-1.1 hbase-server test-jar has incorrect LICENSE
[ https://issues.apache.org/jira/browse/HBASE-14250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706932#comment-14706932 ] Sean Busbey commented on HBASE-14250: - Iterating still. In Nick's logs things show up first in the install and assemble step. Just doing that step by itself doesn't reproduce things. now capturing the logs of each step myself so I can see the maven debug output of that second step. > branch-1.1 hbase-server test-jar has incorrect LICENSE > -- > > Key: HBASE-14250 > URL: https://issues.apache.org/jira/browse/HBASE-14250 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 1.1.2 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Blocker > > test-jar LICENSE file for hbase-server claims jquery and the orca logo are > present in the jar, when they are not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14281) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2
[ https://issues.apache.org/jira/browse/HBASE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Rose updated HBASE-14281: - Status: Patch Available (was: Open) > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, > part 2 > > > Key: HBASE-14281 > URL: https://issues.apache.org/jira/browse/HBASE-14281 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.2, 1.0.1, 1.0.0 >Reporter: Michael Rose > Attachments: 14281-v1.patch > > > Follow-on issue for HBASE-13329: CellComparator#getMinimumMidpointArray seems > to have had a necessary change omitted and the patch only covered one of the > two places diffIdx could overflow the short. > For some background, we ran into the HBASE-13329 issue where a flush would > cause a regionserver abort. After abort, the region in question would almost > indefinitely sit in the FAILED_OPEN state. Applying the patch from > HBASE-13329 didn't solve the issue, but I noticed a comment in that issue > which applied the same change in CellComparator#getMinimumMidpointArray, but > the change was omitted from the attached patch. > RS abort for reference: > slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing > server shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935) > at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NegativeArraySizeException > at > org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494) > at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) > at > org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14281) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2
[ https://issues.apache.org/jira/browse/HBASE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706943#comment-14706943 ] Ted Yu commented on HBASE-14281: I checked hbase-common/src/main/java/org/apache/hadoop/hbase/CellComparator.java in master where the patch no longer applies. For branch-1, diffIdx is declared as int already. > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, > part 2 > > > Key: HBASE-14281 > URL: https://issues.apache.org/jira/browse/HBASE-14281 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.0, 1.0.1, 1.0.2 >Reporter: Michael Rose > Attachments: 14281-v1.patch > > > Follow-on issue for HBASE-13329: CellComparator#getMinimumMidpointArray seems > to have had a necessary change omitted and the patch only covered one of the > two places diffIdx could overflow the short. > For some background, we ran into the HBASE-13329 issue where a flush would > cause a regionserver abort. After abort, the region in question would almost > indefinitely sit in the FAILED_OPEN state. Applying the patch from > HBASE-13329 didn't solve the issue, but I noticed a comment in that issue > which applied the same change in CellComparator#getMinimumMidpointArray, but > the change was omitted from the attached patch. > RS abort for reference: > slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing > server shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935) > at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NegativeArraySizeException > at > org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494) > at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) > at > org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13329) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray
[ https://issues.apache.org/jira/browse/HBASE-13329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706901#comment-14706901 ] Michael Rose commented on HBASE-13329: -- https://issues.apache.org/jira/browse/HBASE-14281 follow-on > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray > > > Key: HBASE-13329 > URL: https://issues.apache.org/jira/browse/HBASE-13329 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.1 > Environment: linux-debian-jessie > ec2 - t2.micro instances >Reporter: Ruben Aguiar >Assignee: Lars Hofhansl >Priority: Critical > Fix For: 2.0.0, 1.0.2, 1.2.0, 1.1.2 > > Attachments: 13329-asserts.patch, 13329-v1.patch, 13329.txt, > HBASE-13329.test.00.branch-1.1.patch > > > While trying to benchmark my opentsdb cluster, I've created a script that > sends to hbase always the same value (in this case 1). After a few minutes, > the whole region server crashes and the region itself becomes impossible to > open again (cannot assign or unassign). After some investigation, what I saw > on the logs is that when a Memstore flush is called on a large region (128mb) > the process errors, killing the regionserver. On restart, replaying the edits > generates the same error, making the region unavailable. Tried to manually > unassign, assign or close_region. That didn't work because the code that > reads/replays it crashes. > From my investigation this seems to be an overflow issue. The logs show that > the function getMinimumMidpointArray tried to access index -32743 of an > array, extremely close to the minimum short value in Java. Upon investigation > of the source code, it seems an index short is used, being incremented as > long as the two vectors are the same, probably making it overflow on large > vectors with equal data. Changing it to int should solve the problem. > Here follows the hadoop logs of when the regionserver went down. Any help is > appreciated. Any other information you need please do tell me: > 2015-03-24 18:00:56,187 INFO [regionserver//10.2.0.73:16020.logRoller] > wal.FSHLog: Rolled WAL > /hbase/WALs/10.2.0.73,16020,1427216382590/10.2.0.73%2C16020%2C1427216382590.default.1427220018516 > with entries=143, filesize=134.70 MB; new WAL > /hbase/WALs/10.2.0.73,16020,1427216382590/10.2.0.73%2C16020%2C1427216382590.default.1427220056140 > 2015-03-24 18:00:56,188 INFO [regionserver//10.2.0.73:16020.logRoller] > wal.FSHLog: Archiving > hdfs://10.2.0.74:8020/hbase/WALs/10.2.0.73,16020,1427216382590/10.2.0.73%2C16020%2C1427216382590.default.1427219987709 > to > hdfs://10.2.0.74:8020/hbase/oldWALs/10.2.0.73%2C16020%2C1427216382590.default.1427219987709 > 2015-03-24 18:04:35,722 INFO [MemStoreFlusher.0] regionserver.HRegion: > Started memstore flush for > tsdb,,1427133969325.52bc1994da0fea97563a4a656a58bec2., current region > memstore size 128.04 MB > 2015-03-24 18:04:36,154 FATAL [MemStoreFlusher.0] regionserver.HRegionServer: > ABORTING region server 10.2.0.73,16020,1427216382590: Replay of WAL required. > Forcing server shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > tsdb,,1427133969325.52bc1994da0fea97563a4a656a58bec2. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1999) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1770) > at > org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1702) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:445) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:407) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:69) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:225) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.ArrayIndexOutOfBoundsException: -32743 > at > org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:478) > at > org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV3.append(HFileWriterV3.java:87) > at > org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:932) > at > org.apach
[jira] [Commented] (HBASE-14281) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2
[ https://issues.apache.org/jira/browse/HBASE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706951#comment-14706951 ] Michael Rose commented on HBASE-14281: -- Interesting, the blame says it landed in HBASE-13329, but it wasn't in the patch for that issue. Apologies for not checking the branch first, I was working off 1.0.0. > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, > part 2 > > > Key: HBASE-14281 > URL: https://issues.apache.org/jira/browse/HBASE-14281 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.0, 1.0.1, 1.0.2 >Reporter: Michael Rose > Attachments: 14281-v1.patch > > > Follow-on issue for HBASE-13329: CellComparator#getMinimumMidpointArray seems > to have had a necessary change omitted and the patch only covered one of the > two places diffIdx could overflow the short. > For some background, we ran into the HBASE-13329 issue where a flush would > cause a regionserver abort. After abort, the region in question would almost > indefinitely sit in the FAILED_OPEN state. Applying the patch from > HBASE-13329 didn't solve the issue, but I noticed a comment in that issue > which applied the same change in CellComparator#getMinimumMidpointArray, but > the change was omitted from the attached patch. > RS abort for reference: > slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing > server shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935) > at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NegativeArraySizeException > at > org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494) > at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) > at > org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14281) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2
[ https://issues.apache.org/jira/browse/HBASE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-14281: Assignee: Michael Rose > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, > part 2 > > > Key: HBASE-14281 > URL: https://issues.apache.org/jira/browse/HBASE-14281 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.0, 1.0.1, 1.0.2 >Reporter: Michael Rose >Assignee: Michael Rose > Attachments: 14281-v1.patch > > > Follow-on issue for HBASE-13329: CellComparator#getMinimumMidpointArray seems > to have had a necessary change omitted and the patch only covered one of the > two places diffIdx could overflow the short. > For some background, we ran into the HBASE-13329 issue where a flush would > cause a regionserver abort. After abort, the region in question would almost > indefinitely sit in the FAILED_OPEN state. Applying the patch from > HBASE-13329 didn't solve the issue, but I noticed a comment in that issue > which applied the same change in CellComparator#getMinimumMidpointArray, but > the change was omitted from the attached patch. > RS abort for reference: > slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing > server shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935) > at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NegativeArraySizeException > at > org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494) > at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) > at > org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14281) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2
[ https://issues.apache.org/jira/browse/HBASE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706955#comment-14706955 ] Michael Rose commented on HBASE-14281: -- The specific change addressed by the patch in HBASE-13329 is not in branch-1 (short diffIdx, KeyValue.java L2367). Any concerns there? > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, > part 2 > > > Key: HBASE-14281 > URL: https://issues.apache.org/jira/browse/HBASE-14281 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.0, 1.0.1, 1.0.2 >Reporter: Michael Rose > Attachments: 14281-v1.patch > > > Follow-on issue for HBASE-13329: CellComparator#getMinimumMidpointArray seems > to have had a necessary change omitted and the patch only covered one of the > two places diffIdx could overflow the short. > For some background, we ran into the HBASE-13329 issue where a flush would > cause a regionserver abort. After abort, the region in question would almost > indefinitely sit in the FAILED_OPEN state. Applying the patch from > HBASE-13329 didn't solve the issue, but I noticed a comment in that issue > which applied the same change in CellComparator#getMinimumMidpointArray, but > the change was omitted from the attached patch. > RS abort for reference: > slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing > server shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935) > at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NegativeArraySizeException > at > org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494) > at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) > at > org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14281) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2
[ https://issues.apache.org/jira/browse/HBASE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706958#comment-14706958 ] Sean Busbey commented on HBASE-14281: - if things aren't fixed in all branches, that's still a bug. If you name your patch HBASE-X-branch-foo.2.patch, then it will test against branch-foo. i.e.: HBASE-14281-branch-1.v2.patch, HBASE-142810-branch-1.0.v2.patch, etc. > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, > part 2 > > > Key: HBASE-14281 > URL: https://issues.apache.org/jira/browse/HBASE-14281 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.0, 1.0.1, 1.0.2 >Reporter: Michael Rose >Assignee: Michael Rose > Attachments: 14281-v1.patch > > > Follow-on issue for HBASE-13329: CellComparator#getMinimumMidpointArray seems > to have had a necessary change omitted and the patch only covered one of the > two places diffIdx could overflow the short. > For some background, we ran into the HBASE-13329 issue where a flush would > cause a regionserver abort. After abort, the region in question would almost > indefinitely sit in the FAILED_OPEN state. Applying the patch from > HBASE-13329 didn't solve the issue, but I noticed a comment in that issue > which applied the same change in CellComparator#getMinimumMidpointArray, but > the change was omitted from the attached patch. > RS abort for reference: > slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing > server shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935) > at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NegativeArraySizeException > at > org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494) > at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) > at > org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14281) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2
[ https://issues.apache.org/jira/browse/HBASE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706961#comment-14706961 ] Ted Yu commented on HBASE-14281: Interesting, that line led to the following JIRA: HBASE-9247 Cleanup Key/KV/Meta/MetaKey Comparators > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, > part 2 > > > Key: HBASE-14281 > URL: https://issues.apache.org/jira/browse/HBASE-14281 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.0, 1.0.1, 1.0.2 >Reporter: Michael Rose >Assignee: Michael Rose > Attachments: 14281-v1.patch > > > Follow-on issue for HBASE-13329: CellComparator#getMinimumMidpointArray seems > to have had a necessary change omitted and the patch only covered one of the > two places diffIdx could overflow the short. > For some background, we ran into the HBASE-13329 issue where a flush would > cause a regionserver abort. After abort, the region in question would almost > indefinitely sit in the FAILED_OPEN state. Applying the patch from > HBASE-13329 didn't solve the issue, but I noticed a comment in that issue > which applied the same change in CellComparator#getMinimumMidpointArray, but > the change was omitted from the attached patch. > RS abort for reference: > slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing > server shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935) > at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NegativeArraySizeException > at > org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494) > at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) > at > org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-14282) Remove metrics2
Elliott Clark created HBASE-14282: - Summary: Remove metrics2 Key: HBASE-14282 URL: https://issues.apache.org/jira/browse/HBASE-14282 Project: HBase Issue Type: Bug Components: metrics Reporter: Elliott Clark Metrics2 has a whole bunch of race conditions and weird edges because of all of the caching that metrics2 does. Additionally tying something so integral to hadoop who has lots of versions we support has been a maintenance nightmare. It would allow us to completely get rid of the compat modules. Rip it out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14260) don't build javadocs for hbase-protocol module
[
https://issues.apache.org/jira/browse/HBASE-14260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706983#comment-14706983
]
Hudson commented on HBASE-14260:
ABORTED: Integrated in HBase-0.98 #1092 (See
[https://builds.apache.org/job/HBase-0.98/1092/])
HBASE-14260 skip javadoc generation for the hbase-protocol generated classes
(busbey: rev 39e6f39be1226fe449624c5973f6cbbc96138e21)
* hbase-protocol/pom.xml
> don't build javadocs for hbase-protocol module
> --
>
> Key: HBASE-14260
> URL: https://issues.apache.org/jira/browse/HBASE-14260
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 0.98.0, 1.0.0, 2.0.0, 1.1.0, 1.2.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0, 1.2.0, 1.1.2, 1.3.0, 0.98.15, 1.0.3
>
> Attachments: HBASE-14260.1.patch
>
>
> I'm not sure I have all the affected versions, but it seems that something is
> amiss in making our javadocs:
> {code}
> mvn -Papache-release -Prelease -DskipTests clean package
> ... SNIP ...
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache HBase ... SUCCESS [ 11.149
> s]
> [INFO] Apache HBase - Checkstyle .. SUCCESS [ 1.249
> s]
> [INFO] Apache HBase - Resource Bundle . SUCCESS [ 0.539
> s]
> [INFO] Apache HBase - Annotations . SUCCESS [ 4.438
> s]
> [INFO] Apache HBase - Protocol SUCCESS [10:15
> min]
> [INFO] Apache HBase - Common .. SUCCESS [ 48.465
> s]
> [INFO] Apache HBase - Procedure ... SUCCESS [ 14.375
> s]
> [INFO] Apache HBase - Client .. SUCCESS [ 45.187
> s]
> [INFO] Apache HBase - Hadoop Compatibility SUCCESS [ 6.998
> s]
> [INFO] Apache HBase - Hadoop Two Compatibility SUCCESS [ 14.891
> s]
> [INFO] Apache HBase - Prefix Tree . SUCCESS [ 14.214
> s]
> [INFO] Apache HBase - Server .. SUCCESS [02:01
> min]
> [INFO] Apache HBase - Testing Util SUCCESS [ 12.779
> s]
> [INFO] Apache HBase - Thrift .. SUCCESS [01:15
> min]
> [INFO] Apache HBase - Shell ... SUCCESS [ 6.649
> s]
> [INFO] Apache HBase - Integration Tests ... SUCCESS [ 6.429
> s]
> [INFO] Apache HBase - Examples SUCCESS [ 13.200
> s]
> [INFO] Apache HBase - Rest SUCCESS [ 27.831
> s]
> [INFO] Apache HBase - Assembly SUCCESS [ 19.400
> s]
> [INFO] Apache HBase - Shaded .. SUCCESS [ 0.419
> s]
> [INFO] Apache HBase - Shaded - Client . SUCCESS [ 23.707
> s]
> [INFO] Apache HBase - Shaded - Server . SUCCESS [ 43.654
> s]
> [INFO] Apache HBase - Spark ... SUCCESS [02:22
> min]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 21:13 min
> [INFO] Finished at: 2015-08-19T15:48:00-05:00
> [INFO] Final Memory: 181M/1513M
> [INFO]
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14269) FuzzyRowFilter omits certain rows when multiple fuzzy key exist
[ https://issues.apache.org/jira/browse/HBASE-14269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706991#comment-14706991 ] Vladimir Rodionov commented on HBASE-14269: --- Yes, the logic inside optimization for getNextHint is broken when fuzzy row has more than one fixed area, when fuzzy row has one fixed area (the most common case, I suppose) - it works and has significant performance gain, the more fuzzy rows - the more gain. One can run test with fuzzy rows such this: ?X?, or ?X. I would not revert HBASE-13761 completely, unsafe implementation for satisfies is correct and 8x times faster than the previous one. It is a shame that scanner's overhead makes this improvement negligible though. [~honma], please revert genNextCellHint, but leave satisfies. I will work on a new patch for HBASE-13761 when I will have time. The most common case of usage is still correct - fuzzy row with one fixed area. > FuzzyRowFilter omits certain rows when multiple fuzzy key exist > --- > > Key: HBASE-14269 > URL: https://issues.apache.org/jira/browse/HBASE-14269 > Project: HBase > Issue Type: Bug > Components: Filters >Reporter: hongbin ma >Assignee: hongbin ma > Attachments: HBASE-14269-v1.patch, HBASE-14269-v2.patch, > HBASE-14269.patch > > > https://issues.apache.org/jira/browse/HBASE-13761 introduced a RowTracker in > FuzzyRowFilter to avoid performing getNextForFuzzyRule() for each fuzzy key > on each getNextCellHint() by maintaining a list of possible row matches for > each fuzzy key. The implementation assumes that the prepared rows will be > matched one by one, so it removes the first row in the list as soon as it is > used. However, this approach may lead to omitting rows in some cases: > Consider a case where we have two fuzzy keys: > 1?1 > 2?2 > and the data is like: > 000 > 111 > 112 > 121 > 122 > 211 > 212 > when the first row 000 fails to match, RowTracker will update possible row > matches with cell 000 and fuzzy keys 1?1,2?2. This will populate RowTracker > with 101 and 202. Then 101 is popped out of RowTracker, hint the scanner to > go to row 101. The scanner will get 111 and find it is a match, and continued > to find that 112 is not a match, getNextCellHint will be called again. Then > comes the bug: Row 101 has been removed out of RowTracker, so RowTracker will > jump to 202. As you see row 121 will be omitted, but it is actually a match > for fuzzy key 1?1. > I will illustrate the bug by adding a new test case in > TestFuzzyRowFilterEndToEnd. Also I will provide the bug fix in my patch. The > idea of the new solution is to maintain a priority queue for all the possible > match rows for each fuzzy key, and whenever getNextCellHint is called, the > elements in the queue that are smaller than the parameter currentCell will be > updated(and re-insert into the queue). The head of queue will always be the > "Next cell hint". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14281) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2
[ https://issues.apache.org/jira/browse/HBASE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707015#comment-14707015 ] Sean Busbey commented on HBASE-14281: - KeyValue has the short diffIdx on all branch 0.98+. presumably the short is also a problem? > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, > part 2 > > > Key: HBASE-14281 > URL: https://issues.apache.org/jira/browse/HBASE-14281 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.0, 1.0.1, 1.0.2 >Reporter: Michael Rose >Assignee: Michael Rose > Attachments: 14281-v1.patch > > > Follow-on issue for HBASE-13329: CellComparator#getMinimumMidpointArray seems > to have had a necessary change omitted and the patch only covered one of the > two places diffIdx could overflow the short. > For some background, we ran into the HBASE-13329 issue where a flush would > cause a regionserver abort. After abort, the region in question would almost > indefinitely sit in the FAILED_OPEN state. Applying the patch from > HBASE-13329 didn't solve the issue, but I noticed a comment in that issue > which applied the same change in CellComparator#getMinimumMidpointArray, but > the change was omitted from the attached patch. > RS abort for reference: > slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing > server shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935) > at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NegativeArraySizeException > at > org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494) > at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) > at > org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14281) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2
[ https://issues.apache.org/jira/browse/HBASE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707018#comment-14707018 ] Michael Rose commented on HBASE-14281: -- It's unknown to me if the patch to change KeyValue to use ints is strictly necessary. Some quick poking around reveals KeyValue#getShortMidpointKey to be deprecated and only be used by KeyValue#calcIndexKey. calcIndexKey is unused in the HBase project @ 1.0.x, but both are public for external use. It'd likely be desirable to update KeyValue#calcIndexKey to use CellComparator's code. > ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, > part 2 > > > Key: HBASE-14281 > URL: https://issues.apache.org/jira/browse/HBASE-14281 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.0.0, 1.0.1, 1.0.2 >Reporter: Michael Rose >Assignee: Michael Rose > Attachments: 14281-v1.patch > > > Follow-on issue for HBASE-13329: CellComparator#getMinimumMidpointArray seems > to have had a necessary change omitted and the patch only covered one of the > two places diffIdx could overflow the short. > For some background, we ran into the HBASE-13329 issue where a flush would > cause a regionserver abort. After abort, the region in question would almost > indefinitely sit in the FAILED_OPEN state. Applying the patch from > HBASE-13329 didn't solve the issue, but I noticed a comment in that issue > which applied the same change in CellComparator#getMinimumMidpointArray, but > the change was omitted from the attached patch. > RS abort for reference: > slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing > server shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935) > at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NegativeArraySizeException > at > org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494) > at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263) > at > org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14282) Remove metrics2
[ https://issues.apache.org/jira/browse/HBASE-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707053#comment-14707053 ] stack commented on HBASE-14282: --- That is a radical thought. > Remove metrics2 > --- > > Key: HBASE-14282 > URL: https://issues.apache.org/jira/browse/HBASE-14282 > Project: HBase > Issue Type: Bug > Components: metrics >Reporter: Elliott Clark > > Metrics2 has a whole bunch of race conditions and weird edges because of all > of the caching that metrics2 does. > Additionally tying something so integral to hadoop who has lots of versions > we support has been a maintenance nightmare. It would allow us to completely > get rid of the compat modules. > Rip it out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14282) Remove metrics2
[ https://issues.apache.org/jira/browse/HBASE-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-14282: -- Priority: Critical (was: Major) Fix Version/s: 2.0.0 Issue Type: Improvement (was: Bug) I wonder how much work would be involved. As long as the over-the-wire JMX and the Beans published were the same, how the metrics are generated could change. Removing compat modules and metrics2 voodoo would be a nice cleanup. > Remove metrics2 > --- > > Key: HBASE-14282 > URL: https://issues.apache.org/jira/browse/HBASE-14282 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Elliott Clark >Priority: Critical > Fix For: 2.0.0 > > > Metrics2 has a whole bunch of race conditions and weird edges because of all > of the caching that metrics2 does. > Additionally tying something so integral to hadoop who has lots of versions > we support has been a maintenance nightmare. It would allow us to completely > get rid of the compat modules. > Rip it out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14282) Remove metrics2
[ https://issues.apache.org/jira/browse/HBASE-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707055#comment-14707055 ] Sean Busbey commented on HBASE-14282: - switch to [coda hale's metrics|https://github.com/dropwizard/metrics]? > Remove metrics2 > --- > > Key: HBASE-14282 > URL: https://issues.apache.org/jira/browse/HBASE-14282 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Elliott Clark >Priority: Critical > Fix For: 2.0.0 > > > Metrics2 has a whole bunch of race conditions and weird edges because of all > of the caching that metrics2 does. > Additionally tying something so integral to hadoop who has lots of versions > we support has been a maintenance nightmare. It would allow us to completely > get rid of the compat modules. > Rip it out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14282) Remove metrics2
[ https://issues.apache.org/jira/browse/HBASE-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707058#comment-14707058 ] Sean Busbey commented on HBASE-14282: - I'll try to make a summary of the discussion that happened aroudn this over in Accumulo. Over there, we just switched to start using Hadoop Metrics 2 in the recent 1.7.0 release: ACCUMULO-1817 > Remove metrics2 > --- > > Key: HBASE-14282 > URL: https://issues.apache.org/jira/browse/HBASE-14282 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Elliott Clark >Priority: Critical > Fix For: 2.0.0 > > > Metrics2 has a whole bunch of race conditions and weird edges because of all > of the caching that metrics2 does. > Additionally tying something so integral to hadoop who has lots of versions > we support has been a maintenance nightmare. It would allow us to completely > get rid of the compat modules. > Rip it out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14269) FuzzyRowFilter omits certain rows when multiple fuzzy key exist
[ https://issues.apache.org/jira/browse/HBASE-14269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707063#comment-14707063 ] Vladimir Rodionov commented on HBASE-14269: --- I was not correct in my previous statement: optimization works correctly for fuzzy rows with one fixed area - it does not fuzzy key - ?5?, ?6? Rows: 151 241 251 but the good news : I have a simple quick for this. I will reassign this JIRA to myself. Will do patch today. Thanks, [~honma] > FuzzyRowFilter omits certain rows when multiple fuzzy key exist > --- > > Key: HBASE-14269 > URL: https://issues.apache.org/jira/browse/HBASE-14269 > Project: HBase > Issue Type: Bug > Components: Filters >Reporter: hongbin ma >Assignee: hongbin ma > Attachments: HBASE-14269-v1.patch, HBASE-14269-v2.patch, > HBASE-14269.patch > > > https://issues.apache.org/jira/browse/HBASE-13761 introduced a RowTracker in > FuzzyRowFilter to avoid performing getNextForFuzzyRule() for each fuzzy key > on each getNextCellHint() by maintaining a list of possible row matches for > each fuzzy key. The implementation assumes that the prepared rows will be > matched one by one, so it removes the first row in the list as soon as it is > used. However, this approach may lead to omitting rows in some cases: > Consider a case where we have two fuzzy keys: > 1?1 > 2?2 > and the data is like: > 000 > 111 > 112 > 121 > 122 > 211 > 212 > when the first row 000 fails to match, RowTracker will update possible row > matches with cell 000 and fuzzy keys 1?1,2?2. This will populate RowTracker > with 101 and 202. Then 101 is popped out of RowTracker, hint the scanner to > go to row 101. The scanner will get 111 and find it is a match, and continued > to find that 112 is not a match, getNextCellHint will be called again. Then > comes the bug: Row 101 has been removed out of RowTracker, so RowTracker will > jump to 202. As you see row 121 will be omitted, but it is actually a match > for fuzzy key 1?1. > I will illustrate the bug by adding a new test case in > TestFuzzyRowFilterEndToEnd. Also I will provide the bug fix in my patch. The > idea of the new solution is to maintain a priority queue for all the possible > match rows for each fuzzy key, and whenever getNextCellHint is called, the > elements in the queue that are smaller than the parameter currentCell will be > updated(and re-insert into the queue). The head of queue will always be the > "Next cell hint". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-14269) FuzzyRowFilter omits certain rows when multiple fuzzy key exist
[ https://issues.apache.org/jira/browse/HBASE-14269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov reassigned HBASE-14269: - Assignee: Vladimir Rodionov (was: hongbin ma) > FuzzyRowFilter omits certain rows when multiple fuzzy key exist > --- > > Key: HBASE-14269 > URL: https://issues.apache.org/jira/browse/HBASE-14269 > Project: HBase > Issue Type: Bug > Components: Filters >Reporter: hongbin ma >Assignee: Vladimir Rodionov > Attachments: HBASE-14269-v1.patch, HBASE-14269-v2.patch, > HBASE-14269.patch > > > https://issues.apache.org/jira/browse/HBASE-13761 introduced a RowTracker in > FuzzyRowFilter to avoid performing getNextForFuzzyRule() for each fuzzy key > on each getNextCellHint() by maintaining a list of possible row matches for > each fuzzy key. The implementation assumes that the prepared rows will be > matched one by one, so it removes the first row in the list as soon as it is > used. However, this approach may lead to omitting rows in some cases: > Consider a case where we have two fuzzy keys: > 1?1 > 2?2 > and the data is like: > 000 > 111 > 112 > 121 > 122 > 211 > 212 > when the first row 000 fails to match, RowTracker will update possible row > matches with cell 000 and fuzzy keys 1?1,2?2. This will populate RowTracker > with 101 and 202. Then 101 is popped out of RowTracker, hint the scanner to > go to row 101. The scanner will get 111 and find it is a match, and continued > to find that 112 is not a match, getNextCellHint will be called again. Then > comes the bug: Row 101 has been removed out of RowTracker, so RowTracker will > jump to 202. As you see row 121 will be omitted, but it is actually a match > for fuzzy key 1?1. > I will illustrate the bug by adding a new test case in > TestFuzzyRowFilterEndToEnd. Also I will provide the bug fix in my patch. The > idea of the new solution is to maintain a priority queue for all the possible > match rows for each fuzzy key, and whenever getNextCellHint is called, the > elements in the queue that are smaller than the parameter currentCell will be > updated(and re-insert into the queue). The head of queue will always be the > "Next cell hint". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14283) Reverse scan doesn’t work with HFile inline index/bloom blocks
[ https://issues.apache.org/jira/browse/HBASE-14283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707088#comment-14707088 ] Ben Lau commented on HBASE-14283: - We suspect the person in HBASE-13830 also ran into this bug, based on his similar exception, but can’t know for sure without more information from him. > Reverse scan doesn’t work with HFile inline index/bloom blocks > -- > > Key: HBASE-14283 > URL: https://issues.apache.org/jira/browse/HBASE-14283 > Project: HBase > Issue Type: Bug >Reporter: Ben Lau >Assignee: Ben Lau > Attachments: hfile-seek-before.patch > > > Reverse scans do not work if an HFile contains inline bloom blocks or leaf > level index blocks. The reason is because the seekBefore() call calculates > the previous data block’s size by assuming data blocks are contiguous which > is not the case in HFile V2 and beyond. > Attached is a first cut patch (targeting > bcef28eefaf192b0ad48c8011f98b8e944340da5 on trunk) which includes: > (1) a unit test which exposes the bug and demonstrates failures for both > inline bloom blocks and inline index blocks > (2) a proposed fix for inline index blocks that does not require a new HFile > version change, but is only performant for 1 and 2-level indexes and not 3+. > 3+ requires an HFile format update for optimal performance. > This patch does not fix the bloom filter blocks bug. But the fix should be > similar to the case of inline index blocks. The reason I haven’t made the > change yet is I want to confirm that you guys would be fine with me revising > the HFile.Reader interface. > Specifically, these 2 functions (getGeneralBloomFilterMetadata and > getDeleteBloomFilterMetadata) need to return the BloomFilter. Right now the > HFileReader class doesn’t have a reference to the bloom filters (and hence > their indices) and only constructs the IO streams and hence has no way to > know where the bloom blocks are in the HFile. It seems that the HFile.Reader > bloom method comments state that they “know nothing about how that metadata > is structured” but I do not know if that is a requirement of the abstraction > (why?) or just an incidental current property. > We would like to do 3 things with community approval: > (1) Update the HFile.Reader interface and implementation to contain and > return BloomFilters directly rather than unstructured IO streams > (2) Merge the fixes for index blocks and bloom blocks into open source > (3) Create a new Jira ticket for open source HBase to add a ‘prevBlockSize’ > field in the block header in the next HFile version, so that seekBefore() > calls can not only be correct but performant in all cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14283) Reverse scan doesn’t work with HFile inline index/bloom blocks
[ https://issues.apache.org/jira/browse/HBASE-14283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Lau updated HBASE-14283: Attachment: hfile-seek-before.patch > Reverse scan doesn’t work with HFile inline index/bloom blocks > -- > > Key: HBASE-14283 > URL: https://issues.apache.org/jira/browse/HBASE-14283 > Project: HBase > Issue Type: Bug >Reporter: Ben Lau >Assignee: Ben Lau > Attachments: hfile-seek-before.patch > > > Reverse scans do not work if an HFile contains inline bloom blocks or leaf > level index blocks. The reason is because the seekBefore() call calculates > the previous data block’s size by assuming data blocks are contiguous which > is not the case in HFile V2 and beyond. > Attached is a first cut patch (targeting > bcef28eefaf192b0ad48c8011f98b8e944340da5 on trunk) which includes: > (1) a unit test which exposes the bug and demonstrates failures for both > inline bloom blocks and inline index blocks > (2) a proposed fix for inline index blocks that does not require a new HFile > version change, but is only performant for 1 and 2-level indexes and not 3+. > 3+ requires an HFile format update for optimal performance. > This patch does not fix the bloom filter blocks bug. But the fix should be > similar to the case of inline index blocks. The reason I haven’t made the > change yet is I want to confirm that you guys would be fine with me revising > the HFile.Reader interface. > Specifically, these 2 functions (getGeneralBloomFilterMetadata and > getDeleteBloomFilterMetadata) need to return the BloomFilter. Right now the > HFileReader class doesn’t have a reference to the bloom filters (and hence > their indices) and only constructs the IO streams and hence has no way to > know where the bloom blocks are in the HFile. It seems that the HFile.Reader > bloom method comments state that they “know nothing about how that metadata > is structured” but I do not know if that is a requirement of the abstraction > (why?) or just an incidental current property. > We would like to do 3 things with community approval: > (1) Update the HFile.Reader interface and implementation to contain and > return BloomFilters directly rather than unstructured IO streams > (2) Merge the fixes for index blocks and bloom blocks into open source > (3) Create a new Jira ticket for open source HBase to add a ‘prevBlockSize’ > field in the block header in the next HFile version, so that seekBefore() > calls can not only be correct but performant in all cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-14283) Reverse scan doesn’t work with HFile inline index/bloom blocks
Ben Lau created HBASE-14283: --- Summary: Reverse scan doesn’t work with HFile inline index/bloom blocks Key: HBASE-14283 URL: https://issues.apache.org/jira/browse/HBASE-14283 Project: HBase Issue Type: Bug Reporter: Ben Lau Assignee: Ben Lau Attachments: hfile-seek-before.patch Reverse scans do not work if an HFile contains inline bloom blocks or leaf level index blocks. The reason is because the seekBefore() call calculates the previous data block’s size by assuming data blocks are contiguous which is not the case in HFile V2 and beyond. Attached is a first cut patch (targeting bcef28eefaf192b0ad48c8011f98b8e944340da5 on trunk) which includes: (1) a unit test which exposes the bug and demonstrates failures for both inline bloom blocks and inline index blocks (2) a proposed fix for inline index blocks that does not require a new HFile version change, but is only performant for 1 and 2-level indexes and not 3+. 3+ requires an HFile format update for optimal performance. This patch does not fix the bloom filter blocks bug. But the fix should be similar to the case of inline index blocks. The reason I haven’t made the change yet is I want to confirm that you guys would be fine with me revising the HFile.Reader interface. Specifically, these 2 functions (getGeneralBloomFilterMetadata and getDeleteBloomFilterMetadata) need to return the BloomFilter. Right now the HFileReader class doesn’t have a reference to the bloom filters (and hence their indices) and only constructs the IO streams and hence has no way to know where the bloom blocks are in the HFile. It seems that the HFile.Reader bloom method comments state that they “know nothing about how that metadata is structured” but I do not know if that is a requirement of the abstraction (why?) or just an incidental current property. We would like to do 3 things with community approval: (1) Update the HFile.Reader interface and implementation to contain and return BloomFilters directly rather than unstructured IO streams (2) Merge the fixes for index blocks and bloom blocks into open source (3) Create a new Jira ticket for open source HBase to add a ‘prevBlockSize’ field in the block header in the next HFile version, so that seekBefore() calls can not only be correct but performant in all cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14282) Remove metrics2
[ https://issues.apache.org/jira/browse/HBASE-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707089#comment-14707089 ] Elliott Clark commented on HBASE-14282: --- [~busbey] Yeah switching to dropwizards was my thought. Metrics2 has just been awful to work with. * It tries to cache things in places that make working with it hard. * Removing metrics is awful at best. * Adding more metrics means way too much work. * It's testability is awful because hadoop mangles names. > Remove metrics2 > --- > > Key: HBASE-14282 > URL: https://issues.apache.org/jira/browse/HBASE-14282 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Elliott Clark >Priority: Critical > Fix For: 2.0.0 > > > Metrics2 has a whole bunch of race conditions and weird edges because of all > of the caching that metrics2 does. > Additionally tying something so integral to hadoop who has lots of versions > we support has been a maintenance nightmare. It would allow us to completely > get rid of the compat modules. > Rip it out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-11062) htop
[ https://issues.apache.org/jira/browse/HBASE-11062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell reassigned HBASE-11062: -- Assignee: Andrew Purtell Consider something like NNtop (HDFS-6982) and YARN top (YARN-3348). Features in common: - Command line utility - Unix top-like presentation (curses-like interface) - Cluster health in display header - Summary utilization metrics - Windowed data collection - Cache data for short periods of time I think our approach would look a lot like HDFS's. All of the necessary information to make NNtop, as you might expect, is collected and exported by a singleton process. We can do something similar with our master. All regionservers already periodically report load statistics to the master, this is what populates data returned by Admin#getClusterStatus. We'd augment the regionserver reports with top-K usage stats. Like HDFS-6982, we'd collect and manage the information as a MetricsSource implementation, thus exposing it by JMX and HTTP for use by a CLI tool. See the patch on HDFS-6982 for as sketch of what a patch for our master might look like. Views to be presented by the CLI tool: * Status header: master uptime, live servers, dead servers, aggregate ops/sec * Default (Table oriented) ** By table, drill down to region ** By user identity ** By client location * Namespace ** By namespace, drill down to table ** By user identity ** By client location * Region ** By column family, drill down to CF ** By key ** By operation type ** By user identity ** By client location * Column family ** By key ** By operation type ** By user identity ** By client location Columns in the views: * Primary sort order * Secondary sort order * Total access count per second * Summary access latency in ms, (avg, p75, p90, p95, p99, max, adjustable with keypress) * Data volume (display unit adjustable with keypress) Sort ordering: ||View||Primary||Secondary|| |Table (default view)|Table|Region| |Table by user|User|Table| |Table by client|Client|Table| |Namespace|Namespace|Table| |Namespace by user|User|Namespace| |Namespace by client|Client|Namespace| |Region by CF (default region view)|Region|CF| |Region by key|Key|Region| |Region by operation|Op type|Region| |Region by user|User|Region| |Region by client|Client|Region| |CF by key (default CF view)|Key|CF| |CF by operation|Op type|CF| |CF by user|User|CF| |CF by client|Client|CF| Where not sorting by operation type we should separate op count and latencies for read and write operations into their own columns. In most views the contents of the secondary sort field won't change. Interesting future ideas: * Monitored tasks (HBASE-4349) * Read replica awareness What else? > htop > > > Key: HBASE-11062 > URL: https://issues.apache.org/jira/browse/HBASE-11062 > Project: HBase > Issue Type: New Feature >Reporter: Andrew Purtell >Assignee: Andrew Purtell > > A top-like monitor could be useful for testing, debugging, operations of > clusters of moderate size, and possibly for diagnosing issues in large > clusters. > Consider a curses interface like the one presented by atop > (http://www.atoptool.nl/images/screenshots/genericw.png) - with aggregate > metrics collected over a monitoring interval in the upper portion of the > pane, and a listing of discrete measurements sorted and filtered by various > criteria in the bottom part of the pane. One might imagine a cluster overview > with cluster aggregate metrics above and a list of regionservers sorted by > utilization below; and a regionserver view with process metrics above and a > list of metrics by operation type below, or a list of client connections, or > a list of threads, sorted by utilization, throughput, or latency. > Generically 'htop' is taken but would be distinctive in the HBase context, a > utility org.apache.hadoop.hbase.HTop > No need necessarily for a curses interface. Could be an external monitor with > a web front end as has been discussed before. I do like the idea of a process > that runs in a terminal because I interact with dev and test HBase clusters > exclusively by SSH. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14239) Branch-1.2 AM can get stuck when meta moves
[ https://issues.apache.org/jira/browse/HBASE-14239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707093#comment-14707093 ] Elliott Clark commented on HBASE-14239: --- Ok so I don't think that we need a full revert of HBASE-13351 the current patch looks like it works well on my cluster. Any reviews ? > Branch-1.2 AM can get stuck when meta moves > --- > > Key: HBASE-14239 > URL: https://issues.apache.org/jira/browse/HBASE-14239 > Project: HBase > Issue Type: Sub-task > Components: Region Assignment >Affects Versions: 1.2.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 1.2.0 > > Attachments: HBASE-14239-v1.patch, HBASE-14239.patch > > > When regions are moving master can get totally stuck trying to talk to meta. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14283) Reverse scan doesn’t work with HFile inline index/bloom blocks
[ https://issues.apache.org/jira/browse/HBASE-14283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707096#comment-14707096 ] Ben Lau commented on HBASE-14283: - In the patch I also added an extra unit test to TestFromClientside, that also tests reverse scan, but is unrelated to this bug, just as an additional test to strengthen the test suite. > Reverse scan doesn’t work with HFile inline index/bloom blocks > -- > > Key: HBASE-14283 > URL: https://issues.apache.org/jira/browse/HBASE-14283 > Project: HBase > Issue Type: Bug >Reporter: Ben Lau >Assignee: Ben Lau > Attachments: hfile-seek-before.patch > > > Reverse scans do not work if an HFile contains inline bloom blocks or leaf > level index blocks. The reason is because the seekBefore() call calculates > the previous data block’s size by assuming data blocks are contiguous which > is not the case in HFile V2 and beyond. > Attached is a first cut patch (targeting > bcef28eefaf192b0ad48c8011f98b8e944340da5 on trunk) which includes: > (1) a unit test which exposes the bug and demonstrates failures for both > inline bloom blocks and inline index blocks > (2) a proposed fix for inline index blocks that does not require a new HFile > version change, but is only performant for 1 and 2-level indexes and not 3+. > 3+ requires an HFile format update for optimal performance. > This patch does not fix the bloom filter blocks bug. But the fix should be > similar to the case of inline index blocks. The reason I haven’t made the > change yet is I want to confirm that you guys would be fine with me revising > the HFile.Reader interface. > Specifically, these 2 functions (getGeneralBloomFilterMetadata and > getDeleteBloomFilterMetadata) need to return the BloomFilter. Right now the > HFileReader class doesn’t have a reference to the bloom filters (and hence > their indices) and only constructs the IO streams and hence has no way to > know where the bloom blocks are in the HFile. It seems that the HFile.Reader > bloom method comments state that they “know nothing about how that metadata > is structured” but I do not know if that is a requirement of the abstraction > (why?) or just an incidental current property. > We would like to do 3 things with community approval: > (1) Update the HFile.Reader interface and implementation to contain and > return BloomFilters directly rather than unstructured IO streams > (2) Merge the fixes for index blocks and bloom blocks into open source > (3) Create a new Jira ticket for open source HBase to add a ‘prevBlockSize’ > field in the block header in the next HFile version, so that seekBefore() > calls can not only be correct but performant in all cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14280) Bulk Upload from HA cluster to remote HA hbase cluster fails
[
https://issues.apache.org/jira/browse/HBASE-14280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707102#comment-14707102
]
Hadoop QA commented on HBASE-14280:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12751712/HBASE-14280_v1.0.patch
against master branch at commit bcef28eefaf192b0ad48c8011f98b8e944340da5.
ATTACHMENT ID: 12751712
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/15199//console
This message is automatically generated.
> Bulk Upload from HA cluster to remote HA hbase cluster fails
>
>
> Key: HBASE-14280
> URL: https://issues.apache.org/jira/browse/HBASE-14280
> Project: HBase
> Issue Type: Bug
> Components: hadoop2, regionserver
>Affects Versions: 0.98.4, 1.1.0.1
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Minor
> Labels: easyfix, patch
> Attachments: HBASE-14280_v1.0.patch
>
>
> Caused by:
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(java.io.IOException):
> java.io.IOException: Wrong FS:
> hdfs://ha-aggregation-nameservice1/hbase_upload/82c89692-6e78-46ef-bbea-c9e825318bfe/A/131358d641c69d6c34b803c187b0,
> expected: hdfs://ha-hbase-nameservice1
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2113)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:108)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:114)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:94)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalArgumentException: Wrong FS:
> hdfs://ha-aggregation-nameservice1/hbase_upload/82c89692-6e78-46ef-bbea-c9e825318bfe/A/131358d641c69d6c34b803c187b0,
> expected: hdfs://ha-hbase-nameservice1
> at org.apache.hadoop.fs.FileSystem.checkPath(FileSystem.java:645)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem.getPathName(DistributedFileSystem.java:193)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem.access$000(DistributedFileSystem.java:105)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:1136)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:1132)
> at
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1132)
> at
> org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:414)
> at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1423)
> at
> org.apache.hadoop.hbase.regionserver.HRegionFileSystem.commitStoreFile(HRegionFileSystem.java:372)
> at
> org.apache.hadoop.hbase.regionserver.HRegionFileSystem.bulkLoadStoreFile(HRegionFileSystem.java:451)
> at
> org.apache.hadoop.hbase.regionserver.HStore.bulkLoadHFile(HStore.java:750)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.bulkLoadHFiles(HRegion.java:4894)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.bulkLoadHFiles(HRegion.java:4799)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.bulkLoadHFile(HRegionServer.java:3377)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29996)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2078)
> ... 4 more
> at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1498)
> at
> org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1684)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1737)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$BlockingStub.bulkLoadHFile(ClientProtos.java:29276)
> at
> org.apache.hadoop.hbase.protobuf.ProtobufUtil.bulkLoadHFile(ProtobufUtil.java:1548)
> ... 11 more
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13830) Hbase REVERSED may throw Exception sometimes
[
https://issues.apache.org/jira/browse/HBASE-13830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707111#comment-14707111
]
Ben Lau commented on HBASE-13830:
-
Possibly the same bug as in HBASE-14283, or related.
> Hbase REVERSED may throw Exception sometimes
>
>
> Key: HBASE-13830
> URL: https://issues.apache.org/jira/browse/HBASE-13830
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.1
>Reporter: ryan.jin
>
> run a scan at hbase shell command.
> {code}
> scan
> 'analytics_access',{ENDROW=>'9223370603647713262-flume01.hadoop-10.32.117.111-373563509',LIMIT=>10,REVERSED=>true}
> {code}
> will throw exception
> {code}
> java.io.IOException: java.io.IOException: Could not seekToPreviousRow
> StoreFileScanner[HFileScanner for reader
> reader=hdfs://nameservice1/hbase/data/default/analytics_access/a54c47c568c00dd07f9d92cfab1accc7/cf/2e3a107e9fec4930859e992b61fb22f6,
> compression=lzo, cacheConf=CacheConfig:enabled [cacheDataOnRead=true]
> [cacheDataOnWrite=false] [cacheIndexesOnWrite=false]
> [cacheBloomsOnWrite=false] [cacheEvictOnClose=false] [cacheCompressed=false],
> firstKey=9223370603542781142-flume01.hadoop-10.32.117.111-378180911/cf:key/1433311994702/Put,
>
> lastKey=9223370603715515112-flume01.hadoop-10.32.117.111-370923552/cf:timestamp/1433139261951/Put,
> avgKeyLen=80, avgValueLen=115, entries=43544340, length=1409247455,
> cur=9223370603647710245-flume01.hadoop-10.32.117.111-373563545/cf:payload/1433207065597/Put/vlen=644/mvcc=0]
> to key
> 9223370603647710245-flume01.hadoop-10.32.117.111-373563545/cf:payload/1433207065597/Put/vlen=644/mvcc=0
> at
> org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekToPreviousRow(StoreFileScanner.java:448)
> at
> org.apache.hadoop.hbase.regionserver.ReversedKeyValueHeap.seekToPreviousRow(ReversedKeyValueHeap.java:88)
> at
> org.apache.hadoop.hbase.regionserver.ReversedStoreScanner.seekToPreviousRow(ReversedStoreScanner.java:128)
> at
> org.apache.hadoop.hbase.regionserver.ReversedStoreScanner.seekToNextRow(ReversedStoreScanner.java:88)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:503)
> at
> org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:140)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.populateResult(HRegion.java:3866)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextInternal(HRegion.java:3946)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:3814)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:3805)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3136)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29497)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2012)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:98)
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.consumerLoop(SimpleRpcScheduler.java:160)
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.access$000(SimpleRpcScheduler.java:38)
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler$1.run(SimpleRpcScheduler.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: On-disk size without header provided is
> 47701, but block header contains 10134. Block offset: -1, data starts with:
> DATABLK*\x00\x00'\x96\x00\x01\x00\x04\x00\x00\x00\x005\x96^\xD2\x01\x00\x00@\x00\x00\x00'
> at
> org.apache.hadoop.hbase.io.hfile.HFileBlock.validateOnDiskSizeWithoutHeader(HFileBlock.java:451)
> at
> org.apache.hadoop.hbase.io.hfile.HFileBlock.access$400(HFileBlock.java:87)
> at
> org.apache.hadoop.hbase.io.hfile.HFileBlock$FSReaderV2.readBlockDataInternal(HFileBlock.java:1466)
> at
> org.apache.hadoop.hbase.io.hfile.HFileBlock$FSReaderV2.readBlockData(HFileBlock.java:1314)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:355)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2$AbstractScannerV2.seekBefore(HFileReaderV2.java:569)
> at
> org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekToPreviousRow(StoreFileScanner.java:413)
> ... 17 more
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method) ~[na:1.6.0_65]
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> ~[na:1.6.0_65]
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> ~[na:1.6.0_65]
> at java.lang.reflect.Cons
[jira] [Commented] (HBASE-14282) Remove metrics2
[ https://issues.apache.org/jira/browse/HBASE-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707107#comment-14707107 ] Elliott Clark commented on HBASE-14282: --- [~stack] Not sure if it's possible to do this without changing the metrics names. > Remove metrics2 > --- > > Key: HBASE-14282 > URL: https://issues.apache.org/jira/browse/HBASE-14282 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Elliott Clark >Priority: Critical > Fix For: 2.0.0 > > > Metrics2 has a whole bunch of race conditions and weird edges because of all > of the caching that metrics2 does. > Additionally tying something so integral to hadoop who has lots of versions > we support has been a maintenance nightmare. It would allow us to completely > get rid of the compat modules. > Rip it out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-14284) In TRUNK, AsyncRpcClient does not timeout; hangs TestDistributedLogReplay, etc.
stack created HBASE-14284:
-
Summary: In TRUNK, AsyncRpcClient does not timeout; hangs
TestDistributedLogReplay, etc.
Key: HBASE-14284
URL: https://issues.apache.org/jira/browse/HBASE-14284
Project: HBase
Issue Type: Bug
Reporter: stack
Assignee: stack
TestDistributedLogReplay puts up regionservers with *40* priority handlers
each. This makes for TDLR running with many hundreds of threads. Trying to
figure why 40, I see the test can hang if less with all client use stuck never
timing out:
{code}
"RS:2;localhost:58498" prio=5 tid=0x7fd284d4e800 nid=0x416af in
Object.wait() [0x00012952e000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:461)
at
io.netty.util.concurrent.DefaultPromise.await0(DefaultPromise.java:355)
- locked <0x0007dff93ea0> (a org.apache.hadoop.hbase.ipc.AsyncCall)
at
io.netty.util.concurrent.DefaultPromise.await(DefaultPromise.java:266)
at io.netty.util.concurrent.AbstractFuture.get(AbstractFuture.java:42)
at
org.apache.hadoop.hbase.ipc.AsyncRpcClient.call(AsyncRpcClient.java:231)
at
org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:214)
at
org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:288)
at
org.apache.hadoop.hbase.protobuf.generated.RegionServerStatusProtos$RegionServerStatusService$BlockingStub.regionServerReport(RegionServerStatusProtos.java:8994)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.tryRegionServerReport(HRegionServer.java:1148)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:957)
at
org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.runRegionServer(MiniHBaseCluster.java:156)
at
org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.access$000(MiniHBaseCluster.java:108)
at
org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer$1.run(MiniHBaseCluster.java:140)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1594)
at
org.apache.hadoop.hbase.security.User$SecureHadoopUser.runAs(User.java:279)
at
org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.run(MiniHBaseCluster.java:138)
at java.lang.Thread.run(Thread.java:744)
{code}
We never recover.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14258) Make region_mover.rb script case insensitive in regard to hostname
[ https://issues.apache.org/jira/browse/HBASE-14258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707145#comment-14707145 ] Stephen Yuan Jiang commented on HBASE-14258: +1 LGTM > Make region_mover.rb script case insensitive in regard to hostname > -- > > Key: HBASE-14258 > URL: https://issues.apache.org/jira/browse/HBASE-14258 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-14258.patch > > > The script is case sensitive and fails when case of a host name being > unloaded does not match with a case of a region server name returned by HBase > API. > This doc clarifies IETF rules on case insensitivities in DNS: > https://www.ietf.org/rfc/rfc4343.txt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14282) Remove metrics2
[ https://issues.apache.org/jira/browse/HBASE-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707149#comment-14707149 ] stack commented on HBASE-14282: --- bq. Not sure if it's possible to do this without changing the metrics names. Why sir? That'd be a major stickler. > Remove metrics2 > --- > > Key: HBASE-14282 > URL: https://issues.apache.org/jira/browse/HBASE-14282 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Elliott Clark >Priority: Critical > Fix For: 2.0.0 > > > Metrics2 has a whole bunch of race conditions and weird edges because of all > of the caching that metrics2 does. > Additionally tying something so integral to hadoop who has lots of versions > we support has been a maintenance nightmare. It would allow us to completely > get rid of the compat modules. > Rip it out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14275) Backport to 0.98 HBASE-10785 Metas own location should be cached
[ https://issues.apache.org/jira/browse/HBASE-14275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry He updated HBASE-14275: - Fix Version/s: 0.98.15 Status: Patch Available (was: Open) > Backport to 0.98 HBASE-10785 Metas own location should be cached > > > Key: HBASE-14275 > URL: https://issues.apache.org/jira/browse/HBASE-14275 > Project: HBase > Issue Type: Improvement >Reporter: Jerry He >Assignee: Jerry He > Fix For: 0.98.15 > > Attachments: HBASE-14275-0.98.patch > > > We've seen similar problem reported on 0.98. > It is good improvement to have. > This will cover HBASE-10785 and the a later HBASE-11332. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14282) Remove metrics2
[ https://issues.apache.org/jira/browse/HBASE-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707166#comment-14707166 ] Andrew Purtell commented on HBASE-14282: This is something we could do for 2.0 maybe. bq. Not sure if it's possible to do this without changing the metrics names. And that would mean for sure we can only do it for 2.0. Even then migration of ops tooling will be painful for everyone. I'm about to increase our use of Hadoop metrics at least for HBASE-11062. Until we actually switch away it's the best implementation option since everything else uses them, and they are how we plumb metrics to JMX. > Remove metrics2 > --- > > Key: HBASE-14282 > URL: https://issues.apache.org/jira/browse/HBASE-14282 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Elliott Clark >Priority: Critical > Fix For: 2.0.0 > > > Metrics2 has a whole bunch of race conditions and weird edges because of all > of the caching that metrics2 does. > Additionally tying something so integral to hadoop who has lots of versions > we support has been a maintenance nightmare. It would allow us to completely > get rid of the compat modules. > Rip it out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14281) ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray, part 2
[
https://issues.apache.org/jira/browse/HBASE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707167#comment-14707167
]
Hadoop QA commented on HBASE-14281:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12751746/14281-v1.patch
against master branch at commit bcef28eefaf192b0ad48c8011f98b8e944340da5.
ATTACHMENT ID: 12751746
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/15202//console
This message is automatically generated.
> ArrayIndexOutOfBoundsException in CellComparator#getMinimumMidpointArray,
> part 2
>
>
> Key: HBASE-14281
> URL: https://issues.apache.org/jira/browse/HBASE-14281
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 1.0.0, 1.0.1, 1.0.2
>Reporter: Michael Rose
>Assignee: Michael Rose
> Attachments: 14281-v1.patch
>
>
> Follow-on issue for HBASE-13329: CellComparator#getMinimumMidpointArray seems
> to have had a necessary change omitted and the patch only covered one of the
> two places diffIdx could overflow the short.
> For some background, we ran into the HBASE-13329 issue where a flush would
> cause a regionserver abort. After abort, the region in question would almost
> indefinitely sit in the FAILED_OPEN state. Applying the patch from
> HBASE-13329 didn't solve the issue, but I noticed a comment in that issue
> which applied the same change in CellComparator#getMinimumMidpointArray, but
> the change was omitted from the attached patch.
> RS abort for reference:
> slave3.xxx.xxx.xxx,60020,1440131603772: Replay of WAL required. Forcing
> server shutdown
> org.apache.hadoop.hbase.DroppedSnapshotException: region:
> deduplication,P\xDFt\x10\x053e73ceff5a2717d2ba76887ea21a2a8e353d1372\xFE,1438362391124.2bb6a602be6b1bfcea0508af4ba42235.
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2243)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1972)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1935)
> at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1833)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:452)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:413)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$800(MemStoreFlusher.java:70)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:229)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NegativeArraySizeException
> at
> org.apache.hadoop.hbase.CellComparator.getMinimumMidpointArray(CellComparator.java:494)
> at org.apache.hadoop.hbase.CellComparator.getMidpoint(CellComparator.java:448)
> at
> org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishBlock(HFileWriterV2.java:165)
> at
> org.apache.hadoop.hbase.io.hfile.HFileWriterV2.checkBlockBoundary(HFileWriterV2.java:146)
> at
> org.apache.hadoop.hbase.io.hfile.HFileWriterV2.append(HFileWriterV2.java:263)
> at
> org.apache.hadoop.hbase.regionserver.StoreFile$Writer.append(StoreFile.java:949)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14091) Update site documentation with code of conduct and project policy for transgressions
[ https://issues.apache.org/jira/browse/HBASE-14091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707169#comment-14707169 ] Andrew Purtell commented on HBASE-14091: I'm going to commit this today unless objection > Update site documentation with code of conduct and project policy for > transgressions > > > Key: HBASE-14091 > URL: https://issues.apache.org/jira/browse/HBASE-14091 > Project: HBase > Issue Type: Task > Components: documentation, site >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Labels: site > Attachments: HBASE-14091.patch > > > Due to a recent incident on our public mailing lists I think we should update > our site documentation with a section pointing to the Foundation's Code of > Conduct and spelling out our project's possible responses to transgressions. > I will supply proposed text in a comment on this issue for discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13158) When client supports CellBlock, return the result Cells as controller payload for get(Get) API also
[ https://issues.apache.org/jira/browse/HBASE-13158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707172#comment-14707172 ] ramkrishna.s.vasudevan commented on HBASE-13158: +1 for commit. Significant gain observed when testing get based workload with YCSB. Withoutpatch [OVERALL], RunTime(ms), 57690.0 [OVERALL], Throughput(ops/sec), 17334.02669440111 withpatch [OVERALL], RunTime(ms), 48056.0 [OVERALL], Throughput(ops/sec), 20809.05610121525 > When client supports CellBlock, return the result Cells as controller payload > for get(Get) API also > --- > > Key: HBASE-13158 > URL: https://issues.apache.org/jira/browse/HBASE-13158 > Project: HBase > Issue Type: Improvement >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0, 1.3.0 > > Attachments: 13158v4.suggestion.txt, HBASE-13158.patch, > HBASE-13158_V2.patch, HBASE-13158_V3.patch, HBASE-13158_V4.patch, > HBASE-13158_V6.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14282) Remove metrics2
[ https://issues.apache.org/jira/browse/HBASE-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707176#comment-14707176 ] Elliott Clark commented on HBASE-14282: --- bq.Why sir? That'd be a major stickler. All of the different metrics libraries I know of organize mbeans differently and none of the others organize them in the same way as metrics2 from hadoop. > Remove metrics2 > --- > > Key: HBASE-14282 > URL: https://issues.apache.org/jira/browse/HBASE-14282 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Elliott Clark >Priority: Critical > Fix For: 2.0.0 > > > Metrics2 has a whole bunch of race conditions and weird edges because of all > of the caching that metrics2 does. > Additionally tying something so integral to hadoop who has lots of versions > we support has been a maintenance nightmare. It would allow us to completely > get rid of the compat modules. > Rip it out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14268) Improve KeyLocker
[
https://issues.apache.org/jira/browse/HBASE-14268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707175#comment-14707175
]
Hadoop QA commented on HBASE-14268:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12751740/HBASE-14268-V3.patch
against master branch at commit bcef28eefaf192b0ad48c8011f98b8e944340da5.
ATTACHMENT ID: 12751740
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn post-site goal
to fail.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/15197//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/15197//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/15197//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/15197//console
This message is automatically generated.
> Improve KeyLocker
> -
>
> Key: HBASE-14268
> URL: https://issues.apache.org/jira/browse/HBASE-14268
> Project: HBase
> Issue Type: Improvement
> Components: util
>Reporter: Hiroshi Ikeda
>Assignee: Hiroshi Ikeda
>Priority: Minor
> Attachments: HBASE-14268-V2.patch, HBASE-14268-V3.patch,
> HBASE-14268.patch, KeyLockerPerformance.java
>
>
> 1. In the implementation of {{KeyLocker}} it uses atomic variables inside a
> synchronized block, which doesn't make sense. Moreover, logic inside the
> synchronized block is not trivial so that it makes less performance in heavy
> multi-threaded environment.
> 2. {{KeyLocker}} gives an instance of {{RentrantLock}} which is already
> locked, but it doesn't follow the contract of {{ReentrantLock}} because you
> are not allowed to freely invoke lock/unlock methods under that contract.
> That introduces a potential risk; Whenever you see a variable of the type
> {{RentrantLock}}, you should pay attention to what the included instance is
> coming from.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14282) Remove metrics2
[ https://issues.apache.org/jira/browse/HBASE-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707177#comment-14707177 ] Elliott Clark commented on HBASE-14282: --- bq.Until we actually switch away it's the best implementation option since everything else uses them, and they are how we plumb metrics to JMX. For sure. It's served us alright for now and I fully intend to add more. Just as we get deeper and deeper into using it the more it's showing the stress. > Remove metrics2 > --- > > Key: HBASE-14282 > URL: https://issues.apache.org/jira/browse/HBASE-14282 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Elliott Clark >Priority: Critical > Fix For: 2.0.0 > > > Metrics2 has a whole bunch of race conditions and weird edges because of all > of the caching that metrics2 does. > Additionally tying something so integral to hadoop who has lots of versions > we support has been a maintenance nightmare. It would allow us to completely > get rid of the compat modules. > Rip it out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-14285) Improve local log servlet to show last n-KB etc.
Lars George created HBASE-14285: --- Summary: Improve local log servlet to show last n-KB etc. Key: HBASE-14285 URL: https://issues.apache.org/jira/browse/HBASE-14285 Project: HBase Issue Type: Improvement Components: master, regionserver, REST, Thrift Affects Versions: 2.0.0, 1.2.0 Reporter: Lars George Most of the time servers have very large logs laying around and displaying them with the current log servlet is not useful, as it downloads the entire log to the web browser. YARN has a better version which we could use, or simply implement our own. Would be nice if it could paginate to be able to go through a log from front or end in pages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14260) don't build javadocs for hbase-protocol module
[
https://issues.apache.org/jira/browse/HBASE-14260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707180#comment-14707180
]
Hudson commented on HBASE-14260:
FAILURE: Integrated in HBase-1.0 #1023 (See
[https://builds.apache.org/job/HBase-1.0/1023/])
HBASE-14260 skip javadoc generation for the hbase-protocol generated classes
(busbey: rev f4651657963d61fcbc1402fe048bd9eed0fdbce2)
* hbase-protocol/pom.xml
> don't build javadocs for hbase-protocol module
> --
>
> Key: HBASE-14260
> URL: https://issues.apache.org/jira/browse/HBASE-14260
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 0.98.0, 1.0.0, 2.0.0, 1.1.0, 1.2.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0, 1.2.0, 1.1.2, 1.3.0, 0.98.15, 1.0.3
>
> Attachments: HBASE-14260.1.patch
>
>
> I'm not sure I have all the affected versions, but it seems that something is
> amiss in making our javadocs:
> {code}
> mvn -Papache-release -Prelease -DskipTests clean package
> ... SNIP ...
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache HBase ... SUCCESS [ 11.149
> s]
> [INFO] Apache HBase - Checkstyle .. SUCCESS [ 1.249
> s]
> [INFO] Apache HBase - Resource Bundle . SUCCESS [ 0.539
> s]
> [INFO] Apache HBase - Annotations . SUCCESS [ 4.438
> s]
> [INFO] Apache HBase - Protocol SUCCESS [10:15
> min]
> [INFO] Apache HBase - Common .. SUCCESS [ 48.465
> s]
> [INFO] Apache HBase - Procedure ... SUCCESS [ 14.375
> s]
> [INFO] Apache HBase - Client .. SUCCESS [ 45.187
> s]
> [INFO] Apache HBase - Hadoop Compatibility SUCCESS [ 6.998
> s]
> [INFO] Apache HBase - Hadoop Two Compatibility SUCCESS [ 14.891
> s]
> [INFO] Apache HBase - Prefix Tree . SUCCESS [ 14.214
> s]
> [INFO] Apache HBase - Server .. SUCCESS [02:01
> min]
> [INFO] Apache HBase - Testing Util SUCCESS [ 12.779
> s]
> [INFO] Apache HBase - Thrift .. SUCCESS [01:15
> min]
> [INFO] Apache HBase - Shell ... SUCCESS [ 6.649
> s]
> [INFO] Apache HBase - Integration Tests ... SUCCESS [ 6.429
> s]
> [INFO] Apache HBase - Examples SUCCESS [ 13.200
> s]
> [INFO] Apache HBase - Rest SUCCESS [ 27.831
> s]
> [INFO] Apache HBase - Assembly SUCCESS [ 19.400
> s]
> [INFO] Apache HBase - Shaded .. SUCCESS [ 0.419
> s]
> [INFO] Apache HBase - Shaded - Client . SUCCESS [ 23.707
> s]
> [INFO] Apache HBase - Shaded - Server . SUCCESS [ 43.654
> s]
> [INFO] Apache HBase - Spark ... SUCCESS [02:22
> min]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 21:13 min
> [INFO] Finished at: 2015-08-19T15:48:00-05:00
> [INFO] Final Memory: 181M/1513M
> [INFO]
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14280) Bulk Upload from HA cluster to remote HA hbase cluster fails
[ https://issues.apache.org/jira/browse/HBASE-14280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated HBASE-14280: -- Affects Version/s: (was: 1.1.0.1) > Bulk Upload from HA cluster to remote HA hbase cluster fails > > > Key: HBASE-14280 > URL: https://issues.apache.org/jira/browse/HBASE-14280 > Project: HBase > Issue Type: Bug > Components: hadoop2, regionserver >Affects Versions: 0.98.4 >Reporter: Ankit Singhal >Assignee: Ankit Singhal >Priority: Minor > Labels: easyfix, patch > Attachments: HBASE-14280_v1.0.patch > > > Caused by: > org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(java.io.IOException): > java.io.IOException: Wrong FS: > hdfs://ha-aggregation-nameservice1/hbase_upload/82c89692-6e78-46ef-bbea-c9e825318bfe/A/131358d641c69d6c34b803c187b0, > expected: hdfs://ha-hbase-nameservice1 > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2113) > at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:108) > at > org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:114) > at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:94) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalArgumentException: Wrong FS: > hdfs://ha-aggregation-nameservice1/hbase_upload/82c89692-6e78-46ef-bbea-c9e825318bfe/A/131358d641c69d6c34b803c187b0, > expected: hdfs://ha-hbase-nameservice1 > at org.apache.hadoop.fs.FileSystem.checkPath(FileSystem.java:645) > at > org.apache.hadoop.hdfs.DistributedFileSystem.getPathName(DistributedFileSystem.java:193) > at > org.apache.hadoop.hdfs.DistributedFileSystem.access$000(DistributedFileSystem.java:105) > at > org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:1136) > at > org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:1132) > at > org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81) > at > org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1132) > at > org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:414) > at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1423) > at > org.apache.hadoop.hbase.regionserver.HRegionFileSystem.commitStoreFile(HRegionFileSystem.java:372) > at > org.apache.hadoop.hbase.regionserver.HRegionFileSystem.bulkLoadStoreFile(HRegionFileSystem.java:451) > at > org.apache.hadoop.hbase.regionserver.HStore.bulkLoadHFile(HStore.java:750) > at > org.apache.hadoop.hbase.regionserver.HRegion.bulkLoadHFiles(HRegion.java:4894) > at > org.apache.hadoop.hbase.regionserver.HRegion.bulkLoadHFiles(HRegion.java:4799) > at > org.apache.hadoop.hbase.regionserver.HRegionServer.bulkLoadHFile(HRegionServer.java:3377) > at > org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29996) > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2078) > ... 4 more > at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1498) > at > org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1684) > at > org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1737) > at > org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$BlockingStub.bulkLoadHFile(ClientProtos.java:29276) > at > org.apache.hadoop.hbase.protobuf.ProtobufUtil.bulkLoadHFile(ProtobufUtil.java:1548) > ... 11 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14282) Remove metrics2
[ https://issues.apache.org/jira/browse/HBASE-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707182#comment-14707182 ] Sean Busbey commented on HBASE-14282: - couldn't we make an adaptor bean that looked up the new metrics and published them to the old names periodically? > Remove metrics2 > --- > > Key: HBASE-14282 > URL: https://issues.apache.org/jira/browse/HBASE-14282 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Elliott Clark >Priority: Critical > Fix For: 2.0.0 > > > Metrics2 has a whole bunch of race conditions and weird edges because of all > of the caching that metrics2 does. > Additionally tying something so integral to hadoop who has lots of versions > we support has been a maintenance nightmare. It would allow us to completely > get rid of the compat modules. > Rip it out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-14286) Fix spelling error in "safetyBumper" parameter in WALSplitter
Lars George created HBASE-14286:
---
Summary: Fix spelling error in "safetyBumper" parameter in
WALSplitter
Key: HBASE-14286
URL: https://issues.apache.org/jira/browse/HBASE-14286
Project: HBase
Issue Type: Bug
Affects Versions: 2.0.0, 1.2.0
Reporter: Lars George
Priority: Trivial
In {{WALSplitter]] we have this code:
{code}
public static long writeRegionSequenceIdFile(final FileSystem fs, final Path
regiondir,
long newSeqId, long saftyBumper) throws IOException {
{code}
We should fix the parameter name to be {{safetyBumper}}. Same for the JavaDoc
above the method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13408) HBase In-Memory Memstore Compaction
[
https://issues.apache.org/jira/browse/HBASE-13408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707192#comment-14707192
]
Hadoop QA commented on HBASE-13408:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12751563/HBASE-13408-trunk-v02.patch
against master branch at commit bcef28eefaf192b0ad48c8011f98b8e944340da5.
ATTACHMENT ID: 12751563
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 65 new
or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/15205//console
This message is automatically generated.
> HBase In-Memory Memstore Compaction
> ---
>
> Key: HBASE-13408
> URL: https://issues.apache.org/jira/browse/HBASE-13408
> Project: HBase
> Issue Type: New Feature
>Reporter: Eshcar Hillel
> Attachments: HBASE-13408-trunk-v01.patch,
> HBASE-13408-trunk-v02.patch,
> HBaseIn-MemoryMemstoreCompactionDesignDocument-ver02.pdf,
> HBaseIn-MemoryMemstoreCompactionDesignDocument.pdf,
> InMemoryMemstoreCompactionEvaluationResults.pdf,
> InMemoryMemstoreCompactionScansEvaluationResults.pdf
>
>
> A store unit holds a column family in a region, where the memstore is its
> in-memory component. The memstore absorbs all updates to the store; from time
> to time these updates are flushed to a file on disk, where they are
> compacted. Unlike disk components, the memstore is not compacted until it is
> written to the filesystem and optionally to block-cache. This may result in
> underutilization of the memory due to duplicate entries per row, for example,
> when hot data is continuously updated.
> Generally, the faster the data is accumulated in memory, more flushes are
> triggered, the data sinks to disk more frequently, slowing down retrieval of
> data, even if very recent.
> In high-churn workloads, compacting the memstore can help maintain the data
> in memory, and thereby speed up data retrieval.
> We suggest a new compacted memstore with the following principles:
> 1.The data is kept in memory for as long as possible
> 2.Memstore data is either compacted or in process of being compacted
> 3.Allow a panic mode, which may interrupt an in-progress compaction and
> force a flush of part of the memstore.
> We suggest applying this optimization only to in-memory column families.
> A design document is attached.
> This feature was previously discussed in HBASE-5311.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14280) Bulk Upload from HA cluster to remote HA hbase cluster fails
[
https://issues.apache.org/jira/browse/HBASE-14280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707196#comment-14707196
]
Ted Yu commented on HBASE-14280:
{code}
884 2.6.0
{code}
Please don't upgrade hadoop dependency.
Can you use reflection ?
Formatting is off as well: indentation should be 4 spaces.
> Bulk Upload from HA cluster to remote HA hbase cluster fails
>
>
> Key: HBASE-14280
> URL: https://issues.apache.org/jira/browse/HBASE-14280
> Project: HBase
> Issue Type: Bug
> Components: hadoop2, regionserver
>Affects Versions: 0.98.4
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Minor
> Labels: easyfix, patch
> Attachments: HBASE-14280_v1.0.patch
>
>
> Caused by:
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(java.io.IOException):
> java.io.IOException: Wrong FS:
> hdfs://ha-aggregation-nameservice1/hbase_upload/82c89692-6e78-46ef-bbea-c9e825318bfe/A/131358d641c69d6c34b803c187b0,
> expected: hdfs://ha-hbase-nameservice1
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2113)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:108)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:114)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:94)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalArgumentException: Wrong FS:
> hdfs://ha-aggregation-nameservice1/hbase_upload/82c89692-6e78-46ef-bbea-c9e825318bfe/A/131358d641c69d6c34b803c187b0,
> expected: hdfs://ha-hbase-nameservice1
> at org.apache.hadoop.fs.FileSystem.checkPath(FileSystem.java:645)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem.getPathName(DistributedFileSystem.java:193)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem.access$000(DistributedFileSystem.java:105)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:1136)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:1132)
> at
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1132)
> at
> org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:414)
> at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1423)
> at
> org.apache.hadoop.hbase.regionserver.HRegionFileSystem.commitStoreFile(HRegionFileSystem.java:372)
> at
> org.apache.hadoop.hbase.regionserver.HRegionFileSystem.bulkLoadStoreFile(HRegionFileSystem.java:451)
> at
> org.apache.hadoop.hbase.regionserver.HStore.bulkLoadHFile(HStore.java:750)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.bulkLoadHFiles(HRegion.java:4894)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.bulkLoadHFiles(HRegion.java:4799)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.bulkLoadHFile(HRegionServer.java:3377)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29996)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2078)
> ... 4 more
> at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1498)
> at
> org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1684)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1737)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$BlockingStub.bulkLoadHFile(ClientProtos.java:29276)
> at
> org.apache.hadoop.hbase.protobuf.ProtobufUtil.bulkLoadHFile(ProtobufUtil.java:1548)
> ... 11 more
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14282) Remove metrics2
[ https://issues.apache.org/jira/browse/HBASE-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707221#comment-14707221 ] Elliott Clark commented on HBASE-14282: --- Potentially I think that could work. > Remove metrics2 > --- > > Key: HBASE-14282 > URL: https://issues.apache.org/jira/browse/HBASE-14282 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Elliott Clark >Priority: Critical > Fix For: 2.0.0 > > > Metrics2 has a whole bunch of race conditions and weird edges because of all > of the caching that metrics2 does. > Additionally tying something so integral to hadoop who has lots of versions > we support has been a maintenance nightmare. It would allow us to completely > get rid of the compat modules. > Rip it out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-14286) Fix spelling error in "safetyBumper" parameter in WALSplitter
[
https://issues.apache.org/jira/browse/HBASE-14286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Liptak reassigned HBASE-14286:
Assignee: Gabor Liptak
> Fix spelling error in "safetyBumper" parameter in WALSplitter
> -
>
> Key: HBASE-14286
> URL: https://issues.apache.org/jira/browse/HBASE-14286
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0, 1.2.0
>Reporter: Lars George
>Assignee: Gabor Liptak
>Priority: Trivial
>
> In {{WALSplitter]] we have this code:
> {code}
> public static long writeRegionSequenceIdFile(final FileSystem fs, final
> Path regiondir,
> long newSeqId, long saftyBumper) throws IOException {
> {code}
> We should fix the parameter name to be {{safetyBumper}}. Same for the JavaDoc
> above the method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14286) Fix spelling error in "safetyBumper" parameter in WALSplitter
[
https://issues.apache.org/jira/browse/HBASE-14286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Liptak updated HBASE-14286:
-
Attachment: HBASE-14286.1.patch
> Fix spelling error in "safetyBumper" parameter in WALSplitter
> -
>
> Key: HBASE-14286
> URL: https://issues.apache.org/jira/browse/HBASE-14286
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0, 1.2.0
>Reporter: Lars George
>Assignee: Gabor Liptak
>Priority: Trivial
> Attachments: HBASE-14286.1.patch
>
>
> In {{WALSplitter]] we have this code:
> {code}
> public static long writeRegionSequenceIdFile(final FileSystem fs, final
> Path regiondir,
> long newSeqId, long saftyBumper) throws IOException {
> {code}
> We should fix the parameter name to be {{safetyBumper}}. Same for the JavaDoc
> above the method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14286) Fix spelling error in "safetyBumper" parameter in WALSplitter
[
https://issues.apache.org/jira/browse/HBASE-14286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Liptak updated HBASE-14286:
-
Release Note: HBASE-14286 Correct typo in argument name for
WALSplitter.writeRegionSequenceIdFile
Status: Patch Available (was: Open)
> Fix spelling error in "safetyBumper" parameter in WALSplitter
> -
>
> Key: HBASE-14286
> URL: https://issues.apache.org/jira/browse/HBASE-14286
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0, 1.2.0
>Reporter: Lars George
>Assignee: Gabor Liptak
>Priority: Trivial
> Attachments: HBASE-14286.1.patch
>
>
> In {{WALSplitter]] we have this code:
> {code}
> public static long writeRegionSequenceIdFile(final FileSystem fs, final
> Path regiondir,
> long newSeqId, long saftyBumper) throws IOException {
> {code}
> We should fix the parameter name to be {{safetyBumper}}. Same for the JavaDoc
> above the method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14233) Branch-1.2 Merging regions can result in messed up tables
[
https://issues.apache.org/jira/browse/HBASE-14233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707250#comment-14707250
]
Elliott Clark commented on HBASE-14233:
---
I just had something like this happen again. This time it was a region closing
rather than a region merge. It resulted in a region being stuck closing forever.
> Branch-1.2 Merging regions can result in messed up tables
> -
>
> Key: HBASE-14233
> URL: https://issues.apache.org/jira/browse/HBASE-14233
> Project: HBase
> Issue Type: Sub-task
> Components: Region Assignment
>Affects Versions: 1.2.0
>Reporter: Elliott Clark
>Priority: Critical
> Fix For: 1.2.0
>
>
> {code}
> 15/08/17 14:10:50 INFO master.RegionStates: Transition null to
> {6486b9b9409b25f10eb806ec3bad442d state=MERGING_NEW, ts=1439845850422,
> server=hbase508.ash1.facebook.com,16020,1439844470302}
> 15/08/17 14:10:57 INFO master.AssignmentManager: Failed to record merged
> region 6486b9b9409b25f10eb806ec3bad442d
> 15/08/17 14:10:57 ERROR master.AssignmentManager: Failed to transtion region
> from {6486b9b9409b25f10eb806ec3bad442d state=MERGING_NEW, ts=1439845850422,
> server=hbase508.ash1.facebook.com,16020,1439844470302} to MERGE_PONR by
> hbase508.ash1.facebook.com,16020,1439844470302: Failed to record the merging
> in meta
> 15/08/17 14:11:08 WARN master.RegionStates: THIS SHOULD NOT HAPPEN:
> unexpected {6486b9b9409b25f10eb806ec3bad442d state=MERGING_NEW,
> ts=1439845857580, server=hbase508.ash1.facebook.com,16020,1439844470302}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14253) update docs + build for maven 3.0.4+
[
https://issues.apache.org/jira/browse/HBASE-14253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707257#comment-14707257
]
Sean Busbey commented on HBASE-14253:
-
I can't imagine the build bot backlog is this extensive. Barring objection, I'm
going to push this later today.
> update docs + build for maven 3.0.4+
>
>
> Key: HBASE-14253
> URL: https://issues.apache.org/jira/browse/HBASE-14253
> Project: HBase
> Issue Type: Task
> Components: build, documentation
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Lars Francke
> Labels: beginner
> Attachments: HBASE-14253.patch
>
>
> our new hbase-spark module raises our minimum maven version from 3.0.0
> (though I've only tried 3.0.3) to 3.0.4:
> {code}
> [ERROR] Failed to execute goal
> net.alchim31.maven:scala-maven-plugin:3.2.0:add-source (scala-compile-first)
> on project hbase-spark: The plugin
> net.alchim31.maven:scala-maven-plugin:3.2.0 requires Maven version 3.0.4 ->
> [Help 1]
> {code}
> Update the docs to call out 3.0.4 and add an enforcer rule so that this
> failure can happen at the start of a build rather than 15 minutes in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13158) When client supports CellBlock, return the result Cells as controller payload for get(Get) API also
[ https://issues.apache.org/jira/browse/HBASE-13158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707273#comment-14707273 ] stack commented on HBASE-13158: --- Patch looks good. +1 Only comment is that rather than add a VersionInfo, can we not add statics to the VersionInfo class to do what is in VersionUtil? So, how comes Ram has a nice improvement but Anoop shows little to none (smile)? Could it make us go slower? > When client supports CellBlock, return the result Cells as controller payload > for get(Get) API also > --- > > Key: HBASE-13158 > URL: https://issues.apache.org/jira/browse/HBASE-13158 > Project: HBase > Issue Type: Improvement >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0, 1.3.0 > > Attachments: 13158v4.suggestion.txt, HBASE-13158.patch, > HBASE-13158_V2.patch, HBASE-13158_V3.patch, HBASE-13158_V4.patch, > HBASE-13158_V6.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14250) branch-1.1 hbase-server test-jar has incorrect LICENSE
[ https://issues.apache.org/jira/browse/HBASE-14250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707286#comment-14707286 ] Nick Dimiduk commented on HBASE-14250: -- Okay, a touch of progress. The LICENSE file is being copied from hbase/hbase-server/target/maven-shared-archive-resources/META-INF/LICENSE. > branch-1.1 hbase-server test-jar has incorrect LICENSE > -- > > Key: HBASE-14250 > URL: https://issues.apache.org/jira/browse/HBASE-14250 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 1.1.2 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Blocker > > test-jar LICENSE file for hbase-server claims jquery and the orca logo are > present in the jar, when they are not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14260) don't build javadocs for hbase-protocol module
[
https://issues.apache.org/jira/browse/HBASE-14260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707287#comment-14707287
]
Hudson commented on HBASE-14260:
FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #1046 (See
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/1046/])
HBASE-14260 skip javadoc generation for the hbase-protocol generated classes
(busbey: rev 39e6f39be1226fe449624c5973f6cbbc96138e21)
* hbase-protocol/pom.xml
> don't build javadocs for hbase-protocol module
> --
>
> Key: HBASE-14260
> URL: https://issues.apache.org/jira/browse/HBASE-14260
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 0.98.0, 1.0.0, 2.0.0, 1.1.0, 1.2.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0, 1.2.0, 1.1.2, 1.3.0, 0.98.15, 1.0.3
>
> Attachments: HBASE-14260.1.patch
>
>
> I'm not sure I have all the affected versions, but it seems that something is
> amiss in making our javadocs:
> {code}
> mvn -Papache-release -Prelease -DskipTests clean package
> ... SNIP ...
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache HBase ... SUCCESS [ 11.149
> s]
> [INFO] Apache HBase - Checkstyle .. SUCCESS [ 1.249
> s]
> [INFO] Apache HBase - Resource Bundle . SUCCESS [ 0.539
> s]
> [INFO] Apache HBase - Annotations . SUCCESS [ 4.438
> s]
> [INFO] Apache HBase - Protocol SUCCESS [10:15
> min]
> [INFO] Apache HBase - Common .. SUCCESS [ 48.465
> s]
> [INFO] Apache HBase - Procedure ... SUCCESS [ 14.375
> s]
> [INFO] Apache HBase - Client .. SUCCESS [ 45.187
> s]
> [INFO] Apache HBase - Hadoop Compatibility SUCCESS [ 6.998
> s]
> [INFO] Apache HBase - Hadoop Two Compatibility SUCCESS [ 14.891
> s]
> [INFO] Apache HBase - Prefix Tree . SUCCESS [ 14.214
> s]
> [INFO] Apache HBase - Server .. SUCCESS [02:01
> min]
> [INFO] Apache HBase - Testing Util SUCCESS [ 12.779
> s]
> [INFO] Apache HBase - Thrift .. SUCCESS [01:15
> min]
> [INFO] Apache HBase - Shell ... SUCCESS [ 6.649
> s]
> [INFO] Apache HBase - Integration Tests ... SUCCESS [ 6.429
> s]
> [INFO] Apache HBase - Examples SUCCESS [ 13.200
> s]
> [INFO] Apache HBase - Rest SUCCESS [ 27.831
> s]
> [INFO] Apache HBase - Assembly SUCCESS [ 19.400
> s]
> [INFO] Apache HBase - Shaded .. SUCCESS [ 0.419
> s]
> [INFO] Apache HBase - Shaded - Client . SUCCESS [ 23.707
> s]
> [INFO] Apache HBase - Shaded - Server . SUCCESS [ 43.654
> s]
> [INFO] Apache HBase - Spark ... SUCCESS [02:22
> min]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 21:13 min
> [INFO] Finished at: 2015-08-19T15:48:00-05:00
> [INFO] Final Memory: 181M/1513M
> [INFO]
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14250) branch-1.1 hbase-server test-jar has incorrect LICENSE
[ https://issues.apache.org/jira/browse/HBASE-14250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707291#comment-14707291 ] Sean Busbey commented on HBASE-14250: - that is immensely helpful. That probably means that the testResources aren't properly being respected, which helps pare down what I need to look at. thanks! (also boo to ~30 minute turn around times on test iteration) > branch-1.1 hbase-server test-jar has incorrect LICENSE > -- > > Key: HBASE-14250 > URL: https://issues.apache.org/jira/browse/HBASE-14250 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 1.1.2 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Blocker > > test-jar LICENSE file for hbase-server claims jquery and the orca logo are > present in the jar, when they are not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14253) update docs + build for maven 3.0.4+
[
https://issues.apache.org/jira/browse/HBASE-14253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707289#comment-14707289
]
Andrew Purtell commented on HBASE-14253:
+1
> update docs + build for maven 3.0.4+
>
>
> Key: HBASE-14253
> URL: https://issues.apache.org/jira/browse/HBASE-14253
> Project: HBase
> Issue Type: Task
> Components: build, documentation
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Lars Francke
> Labels: beginner
> Attachments: HBASE-14253.patch
>
>
> our new hbase-spark module raises our minimum maven version from 3.0.0
> (though I've only tried 3.0.3) to 3.0.4:
> {code}
> [ERROR] Failed to execute goal
> net.alchim31.maven:scala-maven-plugin:3.2.0:add-source (scala-compile-first)
> on project hbase-spark: The plugin
> net.alchim31.maven:scala-maven-plugin:3.2.0 requires Maven version 3.0.4 ->
> [Help 1]
> {code}
> Update the docs to call out 3.0.4 and add an enforcer rule so that this
> failure can happen at the start of a build rather than 15 minutes in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14278) Fix NPE that is showing up since HBASE-14274 went in
[
https://issues.apache.org/jira/browse/HBASE-14278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707294#comment-14707294
]
stack commented on HBASE-14278:
---
Seeing this in a recent patch build run:
{code}
testSplitFailedCompactionAndSplit(org.apache.hadoop.hbase.regionserver.TestSplitTransactionOnCluster)
Time elapsed: 1.494 sec <<< ERROR!
java.io.IOException: java.lang.NullPointerException
at
org.apache.hadoop.hbase.regionserver.MetricsRegionSourceImpl.hashCode(MetricsRegionSourceImpl.java:268)
at
java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:333)
at
java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1175)
at java.util.Collections$SetFromMap.remove(Collections.java:3902)
at
org.apache.hadoop.hbase.regionserver.MetricsRegionAggregateSourceImpl.deregister(MetricsRegionAggregateSourceImpl.java:70)
at
org.apache.hadoop.hbase.regionserver.MetricsRegionSourceImpl.close(MetricsRegionSourceImpl.java:117)
at
org.apache.hadoop.hbase.regionserver.MetricsRegion.close(MetricsRegion.java:41)
at
org.apache.hadoop.hbase.regionserver.HRegion.doClose(HRegion.java:1500)
at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1344)
at
org.apache.hadoop.hbase.regionserver.SplitTransactionImpl.stepsBeforePONR(SplitTransactionImpl.java:322)
at
org.apache.hadoop.hbase.regionserver.SplitTransactionImpl.createDaughters(SplitTransactionImpl.java:242)
at
org.apache.hadoop.hbase.regionserver.SplitTransactionImpl.execute(SplitTransactionImpl.java:456)
at
org.apache.hadoop.hbase.regionserver.TestSplitTransactionOnCluster.testSplitFailedCompactionAndSplit(TestSplitTransactionOnCluster.java:270)
{code}
> Fix NPE that is showing up since HBASE-14274 went in
>
>
> Key: HBASE-14278
> URL: https://issues.apache.org/jira/browse/HBASE-14278
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: stack
>
> Saw this in TestDistributedLogSplitting after HBASE-14274 was applied.
> {code}
> 119113 2015-08-20 15:31:10,704 WARN [HBase-Metrics2-1]
> impl.MetricsConfig(124): Cannot locate configuration: tried
> hadoop-metrics2-hbase.properties,hadoop-metrics2.properties
> 119114 2015-08-20 15:31:10,710 ERROR [HBase-Metrics2-1]
> lib.MethodMetric$2(118): Error invoking method getBlocksTotal
> 119115 java.lang.reflect.InvocationTargetException
> 119116 › at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source)
> 119117 › at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 119118 › at java.lang.reflect.Method.invoke(Method.java:606)
> 119119 › at
> org.apache.hadoop.metrics2.lib.MethodMetric$2.snapshot(MethodMetric.java:111)
> 119120 › at
> org.apache.hadoop.metrics2.lib.MethodMetric.snapshot(MethodMetric.java:144)
> 119121 › at
> org.apache.hadoop.metrics2.lib.MetricsRegistry.snapshot(MetricsRegistry.java:387)
> 119122 › at
> org.apache.hadoop.metrics2.lib.MetricsSourceBuilder$1.getMetrics(MetricsSourceBuilder.java:79)
> 119123 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getMetrics(MetricsSourceAdapter.java:195)
> 119124 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.updateJmxCache(MetricsSourceAdapter.java:172)
> 119125 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getMBeanInfo(MetricsSourceAdapter.java:151)
> 119126 › at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getNewMBeanClassName(DefaultMBeanServerInterceptor.java:333)
> 119127 › at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:319)
> 119128 › at
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> 119129 › at org.apache.hadoop.metrics2.util.MBeans.register(MBeans.java:57)
> 119130 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.startMBeans(MetricsSourceAdapter.java:221)
> 119131 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.start(MetricsSourceAdapter.java:96)
> 119132 › at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.registerSource(MetricsSystemImpl.java:245)
> 119133 › at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl$1.postStart(MetricsSystemImpl.java:229)
> 119134 › at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
> 119135 › at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 119136 › at java.lang.reflect.Method.invoke(Method.java:606)
> 119137 › at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl$3.invoke(MetricsSystemImpl.java:290)
> 119138 › at com.sun.proxy.$Proxy13.postStart(Unknown Source)
> 119139 › at
> o
[jira] [Commented] (HBASE-14278) Fix NPE that is showing up since HBASE-14274 went in
[
https://issues.apache.org/jira/browse/HBASE-14278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707298#comment-14707298
]
Elliott Clark commented on HBASE-14278:
---
Blah tests are making this code so ugly. That test double closes the same
region.
> Fix NPE that is showing up since HBASE-14274 went in
>
>
> Key: HBASE-14278
> URL: https://issues.apache.org/jira/browse/HBASE-14278
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: stack
>
> Saw this in TestDistributedLogSplitting after HBASE-14274 was applied.
> {code}
> 119113 2015-08-20 15:31:10,704 WARN [HBase-Metrics2-1]
> impl.MetricsConfig(124): Cannot locate configuration: tried
> hadoop-metrics2-hbase.properties,hadoop-metrics2.properties
> 119114 2015-08-20 15:31:10,710 ERROR [HBase-Metrics2-1]
> lib.MethodMetric$2(118): Error invoking method getBlocksTotal
> 119115 java.lang.reflect.InvocationTargetException
> 119116 › at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source)
> 119117 › at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 119118 › at java.lang.reflect.Method.invoke(Method.java:606)
> 119119 › at
> org.apache.hadoop.metrics2.lib.MethodMetric$2.snapshot(MethodMetric.java:111)
> 119120 › at
> org.apache.hadoop.metrics2.lib.MethodMetric.snapshot(MethodMetric.java:144)
> 119121 › at
> org.apache.hadoop.metrics2.lib.MetricsRegistry.snapshot(MetricsRegistry.java:387)
> 119122 › at
> org.apache.hadoop.metrics2.lib.MetricsSourceBuilder$1.getMetrics(MetricsSourceBuilder.java:79)
> 119123 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getMetrics(MetricsSourceAdapter.java:195)
> 119124 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.updateJmxCache(MetricsSourceAdapter.java:172)
> 119125 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getMBeanInfo(MetricsSourceAdapter.java:151)
> 119126 › at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getNewMBeanClassName(DefaultMBeanServerInterceptor.java:333)
> 119127 › at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:319)
> 119128 › at
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> 119129 › at org.apache.hadoop.metrics2.util.MBeans.register(MBeans.java:57)
> 119130 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.startMBeans(MetricsSourceAdapter.java:221)
> 119131 › at
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.start(MetricsSourceAdapter.java:96)
> 119132 › at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.registerSource(MetricsSystemImpl.java:245)
> 119133 › at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl$1.postStart(MetricsSystemImpl.java:229)
> 119134 › at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
> 119135 › at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 119136 › at java.lang.reflect.Method.invoke(Method.java:606)
> 119137 › at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl$3.invoke(MetricsSystemImpl.java:290)
> 119138 › at com.sun.proxy.$Proxy13.postStart(Unknown Source)
> 119139 › at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.start(MetricsSystemImpl.java:185)
> 119140 › at
> org.apache.hadoop.metrics2.impl.JmxCacheBuster$JmxCacheBusterRunnable.run(JmxCacheBuster.java:81)
> 119141 › at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> 119142 › at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 119143 › at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> 119144 › at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> 119145 › at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 119146 › at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 119147 › at java.lang.Thread.run(Thread.java:744)
> 119148 Caused by: java.lang.NullPointerException
> 119149 › at
> org.apache.hadoop.hdfs.server.blockmanagement.BlocksMap.size(BlocksMap.java:198)
> 119150 › at
> org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.getTotalBlocks(BlockManager.java:3158)
> 119151 › at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlocksTotal(FSNamesystem.java:5652)
> 119152 › ... 32 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
