[jira] [Updated] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Liu Shaohui updated HBASE-10370:
Attachment: HBASE-10370-v2.diff
Update the log as [~zjushch]'s advice
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Attachments: HBASE-10370-v1.diff, HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (HBASE-10374) add jemalloc into the choice of memstore allocation
Bing Jiang created HBASE-10374: -- Summary: add jemalloc into the choice of memstore allocation Key: HBASE-10374 URL: https://issues.apache.org/jira/browse/HBASE-10374 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.96.1.1 Reporter: Bing Jiang Priority: Minor https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead introduced that Netty used jemalloc to gain benefits from GC. It can be a good choice for memstore block allocation. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10349) Table became unusable when master balanced its region after table was dropped
[
https://issues.apache.org/jira/browse/HBASE-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874613#comment-13874613
]
Matteo Bertozzi commented on HBASE-10349:
-
[~jxiang] can you explain why the region is still in META?
the patch looks good to me to avoid any assignment transition after delete,
but I still don't see anything in the balancer/assignment manager that can add
back the region to META.
Table became unusable when master balanced its region after table was dropped
-
Key: HBASE-10349
URL: https://issues.apache.org/jira/browse/HBASE-10349
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.0
Reporter: Ted Yu
Assignee: Jimmy Xiang
Fix For: 0.98.0, 0.99.0
Attachments:
10349-hadoop-hdfs-namenode-hor11n14.gq1.ygridcore.net.zip, 10349-output.log,
10349-v1.txt, 10349-v2.txt, HBASE-10349-meta-test-and-debug.patch,
hbase-10349.patch, hbase-hbase-master-hor15n05.gq1.ygridcore.net.log.tar.gz
0.98 was used.
This was sequence of events:
create 'tablethree_mod'
snapshot 'tablethree_mod', 'snapshot_tablethree_mod'
disable 'tablethree_mod'
2014-01-15 09:34:51,749 restore_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:35:07,210 enable 'tablethree_mod'
2014-01-15 09:35:46,134 delete_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:41:42,210 disable 'tablethree_mod'
2014-01-15 09:41:43,610 drop 'tablethree_mod'
create 'tablethree_mod'
For the last table creation request:
{code}
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'create 'tablethree_mod',
{NAME = 'f1', VERSIONS = 3}
,
{NAME = 'f2', VERSIONS = 3}
,
{NAME = 'f3', VERSIONS = 3}
'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'exists 'tablethree_mod''
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'0', 'f1:q1', 'value-0', 10'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'1', 'f1:q1', 'value-1', 20'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'2', 'f2:q2', 'value-2', 30'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'3', 'f3:q3', 'value-3', 40'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'4', 'f3:q3', 'value-4', 50'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO|Done writing commands to
file. Will execute them now.
2014-01-15 10:03:53,000|beaver.machine|INFO|RUNNING: /usr/lib/hbase/bin/hbase
shell /grid/0/tmp/hwqe/artifacts/tmp-471142
2014-01-15 10:03:55,878|beaver.machine|INFO|2014-01-15 10:03:55,878 INFO
[main] Configuration.deprecation: hadoop.native.lib is deprecated. Instead,
use io.native.lib.available
2014-01-15 10:03:57,283|beaver.machine|INFO|2014-01-15 10:03:57,283 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,669|beaver.machine|INFO|2014-01-15 10:03:57,669 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,720|beaver.machine|INFO|2014-01-15 10:03:57,720 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,997|beaver.machine|INFO|
2014-01-15 10:03:57,997|beaver.machine|INFO|ERROR: Table already exists:
tablethree_mod!
2014-01-15 10:03:57,997|beaver.machine|INFO|
{code}
This was an intermittent issue after using Snapshots, a table is not properly
dropped / and not able to properly re-create with the same name. And a
HRegion is empty or null Error occurs. (When you try to drop the table it
says it does not exist, and when you try to create the table it says that it
does already exist).
{code}
2014-01-15 10:04:02,462|beaver.machine|INFO|ERROR: HRegionInfo was null or
empty in hbase:meta, row=keyvalues=
{tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:seqnumDuringOpen/1389778905355/Put/vlen=8/mvcc=0,
tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:server/1389778905355/Put/vlen=32/mvcc=0,
tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:serverstartcode/1389778905355/Put/vlen=8/mvcc=0}
{code}
Thanks to Huned who discovered this issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874615#comment-13874615
]
ramkrishna.s.vasudevan commented on HBASE-10370:
Patch looks good to me. Did not spend time to check the root cause.
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Attachments: HBASE-10370-v1.diff, HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10030) [JDK8] Erasure of PoolMap#remove(K,V) conflicts with superclass method
[ https://issues.apache.org/jira/browse/HBASE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874632#comment-13874632 ] Eric Charles commented on HBASE-10030: -- finally fails also via the maven command line if I clean before compiling $ mvn -v Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100) Maven home: /opt/apache-maven-3.0.5 Java version: 1.8.0-ea, vendor: Oracle Corporation Java home: /opt/jdk1.8.0-b117/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.12.0-4-generic, arch: amd64, family: unix [JDK8] Erasure of PoolMap#remove(K,V) conflicts with superclass method -- Key: HBASE-10030 URL: https://issues.apache.org/jira/browse/HBASE-10030 Project: HBase Issue Type: Bug Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Trivial Fix For: 0.98.0 Attachments: 10030.patch On JDK 8, the erasure of PoolMap#remove(K,V) conflicts with superclass method remove(Object,Object). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10336) Remove deprecated usage of Hadoop HttpServer in InfoServer
[ https://issues.apache.org/jira/browse/HBASE-10336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Charles updated HBASE-10336: - Attachment: HBASE-10336-5.patch You got it [~stack]. Upon that, please welcome additional config keys (hbase.http.filter.initializers and hbase.http.max.threads) and a separate webapp context attribute (CONF_CONTEXT_ATTRIBUTE = hbase.conf) which would allow mixed hadoop/hbase webapp to coexist in the same JVM (quite theorical, but could be useful for extended embedeed minicluster test cases). The attached patch HBASE-10336-5.patch adds in hbase-default.xml the 2 new keys and pulls 2 more needed test classes from hadoop. About the pom, yes I have thought about the exclusion/inclusion exercise, but would really prefer to perform this when submitting another patch via HBASE-6581. For now, I have quite some branches and would prefer rebasing on trunk. And yes, if you commit to trunk, everything compiles/works as before on the various hadoop versions. So to me, you can commit HBASE-10336-5.patch. Remove deprecated usage of Hadoop HttpServer in InfoServer -- Key: HBASE-10336 URL: https://issues.apache.org/jira/browse/HBASE-10336 Project: HBase Issue Type: Bug Affects Versions: 0.99.0 Reporter: Eric Charles Attachments: HBASE-10336-1.patch, HBASE-10336-2.patch, HBASE-10336-3.patch, HBASE-10336-4.patch, HBASE-10336-5.patch Recent changes in Hadoop HttpServer give NPE when running on hadoop 3.0.0-SNAPSHOT. This way we use HttpServer is deprecated and will probably be not fixed (see HDFS-5760). We'd better move to the new proposed builder pattern, which means we can no more use inheritance to build our nice InfoServer. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874689#comment-13874689
]
Hadoop QA commented on HBASE-10370:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12623612/HBASE-10370-v2.diff
against trunk revision .
ATTACHMENT ID: 12623612
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8459//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8459//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8459//console
This message is automatically generated.
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Attachments: HBASE-10370-v1.diff, HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store
[jira] [Commented] (HBASE-10333) Assignments are not retained on a cluster start
[ https://issues.apache.org/jira/browse/HBASE-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874721#comment-13874721 ] Hudson commented on HBASE-10333: FAILURE: Integrated in hbase-0.96-hadoop2 #177 (See [https://builds.apache.org/job/hbase-0.96-hadoop2/177/]) HBASE-10333 Assignments are not retained on a cluster start (jxiang: rev 1558965) * /hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * /hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java Assignments are not retained on a cluster start --- Key: HBASE-10333 URL: https://issues.apache.org/jira/browse/HBASE-10333 Project: HBase Issue Type: Bug Affects Versions: 0.98.0, 0.96.1.1 Reporter: Devaraj Das Assignee: Jimmy Xiang Fix For: 0.98.0, 0.96.2, 0.99.0 Attachments: hbase-10333.patch When a cluster is fully shutdown and then started up again with hbase.master.startup.retainassign set to true, I noticed that the assignments are not retained. Upon digging, it seems like HBASE-10101 made a change due to which the server holding the META previously is added to dead-servers (in _HMaster.assignMeta_). Later on, this makes the AssignmentManager think that the master recovered from a failure as opposed to a fresh cluster start (the ServerManager.deadServers list is not empty in the check within _AssignmentManager.processDeadServersAndRegionsInTransition_) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10289) Avoid random port usage by default JMX Server. Create Custome JMX server
[ https://issues.apache.org/jira/browse/HBASE-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nijel updated HBASE-10289: -- Attachment: HBASE-10289.patch Attached initial patch with the Custom JMX server. Please have a look. If it is ok, i will change the main classes to start this JMX server. Avoid random port usage by default JMX Server. Create Custome JMX server Key: HBASE-10289 URL: https://issues.apache.org/jira/browse/HBASE-10289 Project: HBase Issue Type: Improvement Reporter: nijel Priority: Minor Attachments: HBASE-10289.patch If we enable JMX MBean server for HMaster or Region server through VM arguments, the process will use one random which we cannot configure. This can be a problem if that random port is configured for some other service. This issue can be avoided by supporting a custom JMX Server. The ports can be configured. If there is no ports configured, it will continue the same way as now. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10366) 0.94 filterRow() may be skipped in 0.96(or onwards) code
[
https://issues.apache.org/jira/browse/HBASE-10366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874869#comment-13874869
]
Ted Yu commented on HBASE-10366:
The javadoc in Filter.java should be revised:
{code}
* @return True if this filter actively uses filterRow(List) or filterRow().
*/
abstract public boolean hasFilterRow();
{code}
0.94 filterRow() may be skipped in 0.96(or onwards) code
Key: HBASE-10366
URL: https://issues.apache.org/jira/browse/HBASE-10366
Project: HBase
Issue Type: Bug
Components: Filters
Reporter: Jeffrey Zhong
Assignee: Jeffrey Zhong
Priority: Critical
Fix For: 0.98.0, 0.96.2
Attachments: hbase-10366.patch
HBASE-6429 combines both filterRow filterRow(ListKeyValue kvs) functions
in Filter.
While 0.94 code or older, it may not implement hasFilterRow as HBase-6429
expected because 0.94(old) hasFilterRow only returns true when
filterRow(ListKeyValue kvs) is overridden not the filterRow(). Therefore,
the filterRow() will be skipped.
Since we don't ask 0.94 users to update their existing filter code, the issue
will cause scan returns unexpected keyvalues and break the backward
compatibility.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10366) 0.94 filterRow() may be skipped in 0.96(or onwards) code
[ https://issues.apache.org/jira/browse/HBASE-10366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874886#comment-13874886 ] stack commented on HBASE-10366: --- Echo what Andrew says for 0.96 0.94 filterRow() may be skipped in 0.96(or onwards) code Key: HBASE-10366 URL: https://issues.apache.org/jira/browse/HBASE-10366 Project: HBase Issue Type: Bug Components: Filters Reporter: Jeffrey Zhong Assignee: Jeffrey Zhong Priority: Critical Fix For: 0.98.0, 0.96.2 Attachments: hbase-10366.patch HBASE-6429 combines both filterRow filterRow(ListKeyValue kvs) functions in Filter. While 0.94 code or older, it may not implement hasFilterRow as HBase-6429 expected because 0.94(old) hasFilterRow only returns true when filterRow(ListKeyValue kvs) is overridden not the filterRow(). Therefore, the filterRow() will be skipped. Since we don't ask 0.94 users to update their existing filter code, the issue will cause scan returns unexpected keyvalues and break the backward compatibility. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10289) Avoid random port usage by default JMX Server. Create Custome JMX server
[ https://issues.apache.org/jira/browse/HBASE-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874889#comment-13874889 ] stack commented on HBASE-10289: --- Tell me more [~nijel] In hbase-env.sh in trunk you can specify ports for JMX (IIRC). Or are you talking about fixing the RMI madness where it picks a random port to respond? With this patch in place, can we remove the talk in hbase-env.sh of flags for starting JMX? What happens if someone passes the flags? Will we have two JMX servers running? Thanks for doing this. Avoid random port usage by default JMX Server. Create Custome JMX server Key: HBASE-10289 URL: https://issues.apache.org/jira/browse/HBASE-10289 Project: HBase Issue Type: Improvement Reporter: nijel Priority: Minor Attachments: HBASE-10289.patch If we enable JMX MBean server for HMaster or Region server through VM arguments, the process will use one random which we cannot configure. This can be a problem if that random port is configured for some other service. This issue can be avoided by supporting a custom JMX Server. The ports can be configured. If there is no ports configured, it will continue the same way as now. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10349) Table became unusable when master balanced its region after table was dropped
[
https://issues.apache.org/jira/browse/HBASE-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Xiang updated HBASE-10349:
Status: Open (was: Patch Available)
Table became unusable when master balanced its region after table was dropped
-
Key: HBASE-10349
URL: https://issues.apache.org/jira/browse/HBASE-10349
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.0
Reporter: Ted Yu
Assignee: Jimmy Xiang
Fix For: 0.98.0, 0.99.0
Attachments:
10349-hadoop-hdfs-namenode-hor11n14.gq1.ygridcore.net.zip, 10349-output.log,
10349-v1.txt, 10349-v2.txt, HBASE-10349-meta-test-and-debug.patch,
hbase-10349.patch, hbase-hbase-master-hor15n05.gq1.ygridcore.net.log.tar.gz
0.98 was used.
This was sequence of events:
create 'tablethree_mod'
snapshot 'tablethree_mod', 'snapshot_tablethree_mod'
disable 'tablethree_mod'
2014-01-15 09:34:51,749 restore_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:35:07,210 enable 'tablethree_mod'
2014-01-15 09:35:46,134 delete_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:41:42,210 disable 'tablethree_mod'
2014-01-15 09:41:43,610 drop 'tablethree_mod'
create 'tablethree_mod'
For the last table creation request:
{code}
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'create 'tablethree_mod',
{NAME = 'f1', VERSIONS = 3}
,
{NAME = 'f2', VERSIONS = 3}
,
{NAME = 'f3', VERSIONS = 3}
'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'exists 'tablethree_mod''
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'0', 'f1:q1', 'value-0', 10'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'1', 'f1:q1', 'value-1', 20'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'2', 'f2:q2', 'value-2', 30'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'3', 'f3:q3', 'value-3', 40'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'4', 'f3:q3', 'value-4', 50'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO|Done writing commands to
file. Will execute them now.
2014-01-15 10:03:53,000|beaver.machine|INFO|RUNNING: /usr/lib/hbase/bin/hbase
shell /grid/0/tmp/hwqe/artifacts/tmp-471142
2014-01-15 10:03:55,878|beaver.machine|INFO|2014-01-15 10:03:55,878 INFO
[main] Configuration.deprecation: hadoop.native.lib is deprecated. Instead,
use io.native.lib.available
2014-01-15 10:03:57,283|beaver.machine|INFO|2014-01-15 10:03:57,283 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,669|beaver.machine|INFO|2014-01-15 10:03:57,669 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,720|beaver.machine|INFO|2014-01-15 10:03:57,720 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,997|beaver.machine|INFO|
2014-01-15 10:03:57,997|beaver.machine|INFO|ERROR: Table already exists:
tablethree_mod!
2014-01-15 10:03:57,997|beaver.machine|INFO|
{code}
This was an intermittent issue after using Snapshots, a table is not properly
dropped / and not able to properly re-create with the same name. And a
HRegion is empty or null Error occurs. (When you try to drop the table it
says it does not exist, and when you try to create the table it says that it
does already exist).
{code}
2014-01-15 10:04:02,462|beaver.machine|INFO|ERROR: HRegionInfo was null or
empty in hbase:meta, row=keyvalues=
{tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:seqnumDuringOpen/1389778905355/Put/vlen=8/mvcc=0,
tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:server/1389778905355/Put/vlen=32/mvcc=0,
tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:serverstartcode/1389778905355/Put/vlen=8/mvcc=0}
{code}
Thanks to Huned who discovered this issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10349) Table became unusable when master balanced its region after table was dropped
[
https://issues.apache.org/jira/browse/HBASE-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874924#comment-13874924
]
Jimmy Xiang commented on HBASE-10349:
-
The test is ok locally. Let me take a look and post a new patch.
[~mbertozzi], it is a racing between table deletion and balancer. The balancer
operates on a copy of the region assignments. When the balancer tries to
balance a region, the region has been deleted (including the meta entry), and
the table is removed (including the znode). In assigning the deleted region,
the region server puts the region back in the meta again with just the server
info. That's why the region info in the meta row is missing.
Table became unusable when master balanced its region after table was dropped
-
Key: HBASE-10349
URL: https://issues.apache.org/jira/browse/HBASE-10349
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.0
Reporter: Ted Yu
Assignee: Jimmy Xiang
Fix For: 0.98.0, 0.99.0
Attachments:
10349-hadoop-hdfs-namenode-hor11n14.gq1.ygridcore.net.zip, 10349-output.log,
10349-v1.txt, 10349-v2.txt, HBASE-10349-meta-test-and-debug.patch,
hbase-10349.patch, hbase-hbase-master-hor15n05.gq1.ygridcore.net.log.tar.gz
0.98 was used.
This was sequence of events:
create 'tablethree_mod'
snapshot 'tablethree_mod', 'snapshot_tablethree_mod'
disable 'tablethree_mod'
2014-01-15 09:34:51,749 restore_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:35:07,210 enable 'tablethree_mod'
2014-01-15 09:35:46,134 delete_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:41:42,210 disable 'tablethree_mod'
2014-01-15 09:41:43,610 drop 'tablethree_mod'
create 'tablethree_mod'
For the last table creation request:
{code}
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'create 'tablethree_mod',
{NAME = 'f1', VERSIONS = 3}
,
{NAME = 'f2', VERSIONS = 3}
,
{NAME = 'f3', VERSIONS = 3}
'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'exists 'tablethree_mod''
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'0', 'f1:q1', 'value-0', 10'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'1', 'f1:q1', 'value-1', 20'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'2', 'f2:q2', 'value-2', 30'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'3', 'f3:q3', 'value-3', 40'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'4', 'f3:q3', 'value-4', 50'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO|Done writing commands to
file. Will execute them now.
2014-01-15 10:03:53,000|beaver.machine|INFO|RUNNING: /usr/lib/hbase/bin/hbase
shell /grid/0/tmp/hwqe/artifacts/tmp-471142
2014-01-15 10:03:55,878|beaver.machine|INFO|2014-01-15 10:03:55,878 INFO
[main] Configuration.deprecation: hadoop.native.lib is deprecated. Instead,
use io.native.lib.available
2014-01-15 10:03:57,283|beaver.machine|INFO|2014-01-15 10:03:57,283 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,669|beaver.machine|INFO|2014-01-15 10:03:57,669 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,720|beaver.machine|INFO|2014-01-15 10:03:57,720 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,997|beaver.machine|INFO|
2014-01-15 10:03:57,997|beaver.machine|INFO|ERROR: Table already exists:
tablethree_mod!
2014-01-15 10:03:57,997|beaver.machine|INFO|
{code}
This was an intermittent issue after using Snapshots, a table is not properly
dropped / and not able to properly re-create with the same name. And a
HRegion is empty or null Error occurs. (When you try to drop the table it
says it does not exist, and when you try to create the table it says that it
does already exist).
{code}
2014-01-15 10:04:02,462|beaver.machine|INFO|ERROR: HRegionInfo was null or
empty in hbase:meta, row=keyvalues=
{tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:seqnumDuringOpen/1389778905355/Put/vlen=8/mvcc=0,
tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:server/1389778905355/Put/vlen=32/mvcc=0,
tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:serverstartcode/1389778905355/Put/vlen=8/mvcc=0}
{code}
Thanks to Huned who discovered this issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10249) Intermittent TestReplicationSyncUpTool failure
[
https://issues.apache.org/jira/browse/HBASE-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874932#comment-13874932
]
Lars Hofhansl commented on HBASE-10249:
---
Yeah, scary stuff, especially since we have multi enabled here. +1
Should change the title to something more descriptive since this in an actual
bug in the replication code.
The condition here is always false, so removing has no effect, right?
{code}
if (parent.equals(rsServerNameZnode)) {
LOG.warn(Won't lock because this is us, we're dead!);
return false;
}
{code}
Intermittent TestReplicationSyncUpTool failure
--
Key: HBASE-10249
URL: https://issues.apache.org/jira/browse/HBASE-10249
Project: HBase
Issue Type: Bug
Reporter: Lars Hofhansl
Assignee: Jean-Daniel Cryans
Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17
Attachments: HBASE-10249-0.94-v0.patch, HBASE-10249-0.94-v1.patch,
HBASE-10249-trunk-v0.patch, HBASE-10249-trunk-v1.patch
New issue to keep track of this.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10123) Change default ports; move them out of linux ephemeral port range
[ https://issues.apache.org/jira/browse/HBASE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-10123: --- Attachment: hbase-10123.v4.patch v4 is what I'm committing to trunk only. Change default ports; move them out of linux ephemeral port range - Key: HBASE-10123 URL: https://issues.apache.org/jira/browse/HBASE-10123 Project: HBase Issue Type: Bug Affects Versions: 0.96.1.1 Reporter: stack Assignee: Jonathan Hsieh Priority: Critical Fix For: 0.98.0 Attachments: hbase-10123.patch, hbase-10123.v2.patch, hbase-10123.v3.patch, hbase-10123.v4.patch Our defaults clash w/ the range linux assigns itself for creating come-and-go ephemeral ports; likely in our history we've clashed w/ a random, short-lived process. While easy to change the defaults, we should just ship w/ defaults that make sense. We could host ourselves up into the 7 or 8k range. See http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10123) Change default ports; move them out of linux ephemeral port range
[ https://issues.apache.org/jira/browse/HBASE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-10123: --- Release Note: After 0.98 hbase's default ports have changed to be outside of the ephemeral port range:. hbase.master.port : 6 - 16000 hbase.master.info.port (http): 60010 - 16010 hbase.regionserver.port : 60020 - 16020 hbase.regionserver.info.port (http): 60030 - 16030 hbase.status.multicast.port : 60100 - 16100 HBase up to and including 0.98.x chose default tcp ports in the 600xx port range which conflicts with the standard unix/linux ephmeral port range of 49152-65535 or 32768-61000. This meant if any other processes chose to bind to a os specified port it could bind to the ports that hbase had as default. If hbase processes were restarted some hbase nodes would fail to start. The probability of this happening increases as the number of nodes in the cluster increases. Hadoop Flags: Incompatible change,Reviewed Change default ports; move them out of linux ephemeral port range - Key: HBASE-10123 URL: https://issues.apache.org/jira/browse/HBASE-10123 Project: HBase Issue Type: Bug Affects Versions: 0.96.1.1 Reporter: stack Assignee: Jonathan Hsieh Priority: Critical Fix For: 0.98.0 Attachments: hbase-10123.patch, hbase-10123.v2.patch, hbase-10123.v3.patch, hbase-10123.v4.patch Our defaults clash w/ the range linux assigns itself for creating come-and-go ephemeral ports; likely in our history we've clashed w/ a random, short-lived process. While easy to change the defaults, we should just ship w/ defaults that make sense. We could host ourselves up into the 7 or 8k range. See http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10123) Change default ports; move them out of linux ephemeral port range
[ https://issues.apache.org/jira/browse/HBASE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874988#comment-13874988 ] Jonathan Hsieh commented on HBASE-10123: Commited to trunk. Thanks for revies. I'vd done minimal doc updates and added release notes. lmk if you guys think I should do more. Change default ports; move them out of linux ephemeral port range - Key: HBASE-10123 URL: https://issues.apache.org/jira/browse/HBASE-10123 Project: HBase Issue Type: Bug Affects Versions: 0.96.1.1 Reporter: stack Assignee: Jonathan Hsieh Priority: Critical Fix For: 0.98.0 Attachments: hbase-10123.patch, hbase-10123.v2.patch, hbase-10123.v3.patch, hbase-10123.v4.patch Our defaults clash w/ the range linux assigns itself for creating come-and-go ephemeral ports; likely in our history we've clashed w/ a random, short-lived process. While easy to change the defaults, we should just ship w/ defaults that make sense. We could host ourselves up into the 7 or 8k range. See http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10123) Change default ports; move them out of linux ephemeral port range
[ https://issues.apache.org/jira/browse/HBASE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-10123: --- Release Note: After 0.98 hbase's default ports have changed to be outside of the ephemeral port range:. hbase.master.port : 6 - 16000 hbase.master.info.port (http): 60010 - 16010 hbase.regionserver.port : 60020 - 16020 hbase.regionserver.info.port (http): 60030 - 16030 hbase.status.multicast.port : 60100 - 16100 To set the old defaults you can add this to your hbase-site.xml: property namehbase.master.port/name value6/value /property property namehbase.master.info.port/name value60010/value /property property namehbase.regionserver.port/name value60020/value /property property namehbase.regionserver.info.port/name value60030/value /property HBase up to and including 0.98.x chose default tcp ports in the 600xx port range which conflicts with the standard unix/linux ephmeral port range of 49152-65535 or 32768-61000. This meant if any other processes chose to bind to a os specified port it could bind to the ports that hbase had as default. If hbase processes were restarted some hbase nodes would fail to start. The probability of this happening increases as the number of nodes in the cluster increases. was: After 0.98 hbase's default ports have changed to be outside of the ephemeral port range:. hbase.master.port : 6 - 16000 hbase.master.info.port (http): 60010 - 16010 hbase.regionserver.port : 60020 - 16020 hbase.regionserver.info.port (http): 60030 - 16030 hbase.status.multicast.port : 60100 - 16100 HBase up to and including 0.98.x chose default tcp ports in the 600xx port range which conflicts with the standard unix/linux ephmeral port range of 49152-65535 or 32768-61000. This meant if any other processes chose to bind to a os specified port it could bind to the ports that hbase had as default. If hbase processes were restarted some hbase nodes would fail to start. The probability of this happening increases as the number of nodes in the cluster increases. Change default ports; move them out of linux ephemeral port range - Key: HBASE-10123 URL: https://issues.apache.org/jira/browse/HBASE-10123 Project: HBase Issue Type: Bug Affects Versions: 0.96.1.1 Reporter: stack Assignee: Jonathan Hsieh Priority: Critical Fix For: 0.98.0 Attachments: hbase-10123.patch, hbase-10123.v2.patch, hbase-10123.v3.patch, hbase-10123.v4.patch Our defaults clash w/ the range linux assigns itself for creating come-and-go ephemeral ports; likely in our history we've clashed w/ a random, short-lived process. While easy to change the defaults, we should just ship w/ defaults that make sense. We could host ourselves up into the 7 or 8k range. See http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10289) Avoid random port usage by default JMX Server. Create Custome JMX server
[ https://issues.apache.org/jira/browse/HBASE-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875000#comment-13875000 ] nijel commented on HBASE-10289: --- can we remove the talk in hbase-env.sh of flags for starting JMX? Avoid random port usage by default JMX Server. Create Custome JMX server Key: HBASE-10289 URL: https://issues.apache.org/jira/browse/HBASE-10289 Project: HBase Issue Type: Improvement Reporter: nijel Priority: Minor Attachments: HBASE-10289.patch If we enable JMX MBean server for HMaster or Region server through VM arguments, the process will use one random which we cannot configure. This can be a problem if that random port is configured for some other service. This issue can be avoided by supporting a custom JMX Server. The ports can be configured. If there is no ports configured, it will continue the same way as now. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10123) Change default ports; move them out of linux ephemeral port range
[ https://issues.apache.org/jira/browse/HBASE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-10123: --- Fix Version/s: (was: 0.98.0) 0.99.0 Change default ports; move them out of linux ephemeral port range - Key: HBASE-10123 URL: https://issues.apache.org/jira/browse/HBASE-10123 Project: HBase Issue Type: Bug Affects Versions: 0.96.1.1 Reporter: stack Assignee: Jonathan Hsieh Priority: Critical Fix For: 0.99.0 Attachments: hbase-10123.patch, hbase-10123.v2.patch, hbase-10123.v3.patch, hbase-10123.v4.patch Our defaults clash w/ the range linux assigns itself for creating come-and-go ephemeral ports; likely in our history we've clashed w/ a random, short-lived process. While easy to change the defaults, we should just ship w/ defaults that make sense. We could host ourselves up into the 7 or 8k range. See http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10375) hbase-default.xml hbase.status.multicast.address.port does not match code
Jonathan Hsieh created HBASE-10375:
--
Summary: hbase-default.xml hbase.status.multicast.address.port
does not match code
Key: HBASE-10375
URL: https://issues.apache.org/jira/browse/HBASE-10375
Project: HBase
Issue Type: Bug
Affects Versions: 0.96.1.1, 0.98.0, 0.99.0
Reporter: Jonathan Hsieh
In hbase-default.xml
{code}
+ property
+namehbase.status.multicast.address.port/name
+value6100/value
+description
+ Multicast port to use for the status publication by multicast.
+/description
+ /property
{code}
In HConstants it was 60100.
{code}
public static final String STATUS_MULTICAST_PORT =
hbase.status.multicast.port;
public static final int DEFAULT_STATUS_MULTICAST_PORT = 16100;
{code}
(it was 60100 in the code for 0.96 and 0.98.)
I lean towards going with the code as opposed to the config file.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10349) Table became unusable when master balanced its region after table was dropped
[
https://issues.apache.org/jira/browse/HBASE-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Xiang updated HBASE-10349:
Attachment: hbase-10349_v2.patch
Attached v2 that fixed the test failures.
Table became unusable when master balanced its region after table was dropped
-
Key: HBASE-10349
URL: https://issues.apache.org/jira/browse/HBASE-10349
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.0
Reporter: Ted Yu
Assignee: Jimmy Xiang
Fix For: 0.98.0, 0.99.0
Attachments:
10349-hadoop-hdfs-namenode-hor11n14.gq1.ygridcore.net.zip, 10349-output.log,
10349-v1.txt, 10349-v2.txt, HBASE-10349-meta-test-and-debug.patch,
hbase-10349.patch, hbase-10349_v2.patch,
hbase-hbase-master-hor15n05.gq1.ygridcore.net.log.tar.gz
0.98 was used.
This was sequence of events:
create 'tablethree_mod'
snapshot 'tablethree_mod', 'snapshot_tablethree_mod'
disable 'tablethree_mod'
2014-01-15 09:34:51,749 restore_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:35:07,210 enable 'tablethree_mod'
2014-01-15 09:35:46,134 delete_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:41:42,210 disable 'tablethree_mod'
2014-01-15 09:41:43,610 drop 'tablethree_mod'
create 'tablethree_mod'
For the last table creation request:
{code}
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'create 'tablethree_mod',
{NAME = 'f1', VERSIONS = 3}
,
{NAME = 'f2', VERSIONS = 3}
,
{NAME = 'f3', VERSIONS = 3}
'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'exists 'tablethree_mod''
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'0', 'f1:q1', 'value-0', 10'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'1', 'f1:q1', 'value-1', 20'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'2', 'f2:q2', 'value-2', 30'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'3', 'f3:q3', 'value-3', 40'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'4', 'f3:q3', 'value-4', 50'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO|Done writing commands to
file. Will execute them now.
2014-01-15 10:03:53,000|beaver.machine|INFO|RUNNING: /usr/lib/hbase/bin/hbase
shell /grid/0/tmp/hwqe/artifacts/tmp-471142
2014-01-15 10:03:55,878|beaver.machine|INFO|2014-01-15 10:03:55,878 INFO
[main] Configuration.deprecation: hadoop.native.lib is deprecated. Instead,
use io.native.lib.available
2014-01-15 10:03:57,283|beaver.machine|INFO|2014-01-15 10:03:57,283 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,669|beaver.machine|INFO|2014-01-15 10:03:57,669 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,720|beaver.machine|INFO|2014-01-15 10:03:57,720 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,997|beaver.machine|INFO|
2014-01-15 10:03:57,997|beaver.machine|INFO|ERROR: Table already exists:
tablethree_mod!
2014-01-15 10:03:57,997|beaver.machine|INFO|
{code}
This was an intermittent issue after using Snapshots, a table is not properly
dropped / and not able to properly re-create with the same name. And a
HRegion is empty or null Error occurs. (When you try to drop the table it
says it does not exist, and when you try to create the table it says that it
does already exist).
{code}
2014-01-15 10:04:02,462|beaver.machine|INFO|ERROR: HRegionInfo was null or
empty in hbase:meta, row=keyvalues=
{tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:seqnumDuringOpen/1389778905355/Put/vlen=8/mvcc=0,
tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:server/1389778905355/Put/vlen=32/mvcc=0,
tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:serverstartcode/1389778905355/Put/vlen=8/mvcc=0}
{code}
Thanks to Huned who discovered this issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10374) add jemalloc into the choice of memstore allocation
[ https://issues.apache.org/jira/browse/HBASE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875022#comment-13875022 ] stack commented on HBASE-10374: --- [~jianbginglover] What you thinking? We pull in netty4, redo our core on top of it (smile), then as a side benefit, use their jemalloc implementation for block cache? Poking around, I don't see it here http://netty.io/4.0/api/index.html Thanks. add jemalloc into the choice of memstore allocation Key: HBASE-10374 URL: https://issues.apache.org/jira/browse/HBASE-10374 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.96.1.1 Reporter: Bing Jiang Priority: Minor https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead introduced that Netty used jemalloc to gain benefits from GC. It can be a good choice for memstore block allocation. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10346) Add Documentation for stateless scanner
[ https://issues.apache.org/jira/browse/HBASE-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875021#comment-13875021 ] Vandana Ayyalasomayajula commented on HBASE-10346: -- [~ndimiduk] Could you review this patch ? Thanks! Add Documentation for stateless scanner --- Key: HBASE-10346 URL: https://issues.apache.org/jira/browse/HBASE-10346 Project: HBase Issue Type: Improvement Components: REST Reporter: Vandana Ayyalasomayajula Assignee: Vandana Ayyalasomayajula Priority: Minor Fix For: 0.98.0, 0.99.0 Attachments: HBASE-10346.0.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10349) Table became unusable when master balanced its region after table was dropped
[
https://issues.apache.org/jira/browse/HBASE-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Xiang updated HBASE-10349:
Status: Patch Available (was: Open)
Table became unusable when master balanced its region after table was dropped
-
Key: HBASE-10349
URL: https://issues.apache.org/jira/browse/HBASE-10349
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.0
Reporter: Ted Yu
Assignee: Jimmy Xiang
Fix For: 0.98.0, 0.99.0
Attachments:
10349-hadoop-hdfs-namenode-hor11n14.gq1.ygridcore.net.zip, 10349-output.log,
10349-v1.txt, 10349-v2.txt, HBASE-10349-meta-test-and-debug.patch,
hbase-10349.patch, hbase-10349_v2.patch,
hbase-hbase-master-hor15n05.gq1.ygridcore.net.log.tar.gz
0.98 was used.
This was sequence of events:
create 'tablethree_mod'
snapshot 'tablethree_mod', 'snapshot_tablethree_mod'
disable 'tablethree_mod'
2014-01-15 09:34:51,749 restore_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:35:07,210 enable 'tablethree_mod'
2014-01-15 09:35:46,134 delete_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:41:42,210 disable 'tablethree_mod'
2014-01-15 09:41:43,610 drop 'tablethree_mod'
create 'tablethree_mod'
For the last table creation request:
{code}
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'create 'tablethree_mod',
{NAME = 'f1', VERSIONS = 3}
,
{NAME = 'f2', VERSIONS = 3}
,
{NAME = 'f3', VERSIONS = 3}
'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'exists 'tablethree_mod''
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'0', 'f1:q1', 'value-0', 10'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'1', 'f1:q1', 'value-1', 20'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'2', 'f2:q2', 'value-2', 30'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'3', 'f3:q3', 'value-3', 40'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'4', 'f3:q3', 'value-4', 50'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO|Done writing commands to
file. Will execute them now.
2014-01-15 10:03:53,000|beaver.machine|INFO|RUNNING: /usr/lib/hbase/bin/hbase
shell /grid/0/tmp/hwqe/artifacts/tmp-471142
2014-01-15 10:03:55,878|beaver.machine|INFO|2014-01-15 10:03:55,878 INFO
[main] Configuration.deprecation: hadoop.native.lib is deprecated. Instead,
use io.native.lib.available
2014-01-15 10:03:57,283|beaver.machine|INFO|2014-01-15 10:03:57,283 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,669|beaver.machine|INFO|2014-01-15 10:03:57,669 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,720|beaver.machine|INFO|2014-01-15 10:03:57,720 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,997|beaver.machine|INFO|
2014-01-15 10:03:57,997|beaver.machine|INFO|ERROR: Table already exists:
tablethree_mod!
2014-01-15 10:03:57,997|beaver.machine|INFO|
{code}
This was an intermittent issue after using Snapshots, a table is not properly
dropped / and not able to properly re-create with the same name. And a
HRegion is empty or null Error occurs. (When you try to drop the table it
says it does not exist, and when you try to create the table it says that it
does already exist).
{code}
2014-01-15 10:04:02,462|beaver.machine|INFO|ERROR: HRegionInfo was null or
empty in hbase:meta, row=keyvalues=
{tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:seqnumDuringOpen/1389778905355/Put/vlen=8/mvcc=0,
tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:server/1389778905355/Put/vlen=32/mvcc=0,
tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:serverstartcode/1389778905355/Put/vlen=8/mvcc=0}
{code}
Thanks to Huned who discovered this issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10289) Avoid random port usage by default JMX Server. Create Custome JMX server
[ https://issues.apache.org/jira/browse/HBASE-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875024#comment-13875024 ] nijel commented on HBASE-10289: --- pls ignore previous comment.. bq. Tell me more nijel In hbase-env.sh in trunk you can specify ports for JMX (IIRC). - Even if we specify the port one of the port will be random. bq. can we remove the talk in hbase-env.sh of flags for starting JMX? - Yes. After this patch we need not specify the flags in hbase-env.sh bq. What happens if someone passes the flags? Will we have two JMX servers running? - Yes, 2 JMX servers will be running. In both the servers beans will be registered. The idea behind this patch is to give a option to user to control the ports used by JMX server. Avoid random port usage by default JMX Server. Create Custome JMX server Key: HBASE-10289 URL: https://issues.apache.org/jira/browse/HBASE-10289 Project: HBase Issue Type: Improvement Reporter: nijel Priority: Minor Attachments: HBASE-10289.patch If we enable JMX MBean server for HMaster or Region server through VM arguments, the process will use one random which we cannot configure. This can be a problem if that random port is configured for some other service. This issue can be avoided by supporting a custom JMX Server. The ports can be configured. If there is no ports configured, it will continue the same way as now. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-8410) Basic quota support for namespaces
[
https://issues.apache.org/jira/browse/HBASE-8410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875038#comment-13875038
]
Ted Yu commented on HBASE-8410:
---
From
https://builds.apache.org/job/PreCommit-HBASE-Build/8456//testReport/org.apache.hadoop.hbase.namespace/TestNamespaceAuditor/testRegionOperations/
:
{code}
2014-01-17 05:27:16,370 INFO [pool-1-thread-1]
namespace.TestNamespaceAuditor(163):
org.apache.hadoop.hbase.DoNotRetryIOException:
org.apache.hadoop.hbase.DoNotRetryIOException: The table
TestNamespaceAuditor_regiontest:table1 is not allowed to have 7 regions. The
total number of regions permitted is only 6, while current region count is 0.
This may be transient, please retry later if there are any ongoing split
operations in the namespace.
at
org.apache.hadoop.hbase.namespace.NamespaceAuditor.checkNamespaceTableCount(NamespaceAuditor.java:322)
at
org.apache.hadoop.hbase.namespace.NamespaceAuditor.preCreateTable(NamespaceAuditor.java:82)
at
org.apache.hadoop.hbase.master.MasterCoprocessorHost.preCreateTable(MasterCoprocessorHost.java:235)
at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:1733)
at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:1766)
at
org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:38221)
at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2008)
at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:92)
at
org.apache.hadoop.hbase.ipc.FifoRpcScheduler$1.run(FifoRpcScheduler.java:73)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
2014-01-17 05:27:16,371 DEBUG [pool-1-thread-1-EventThread]
hbase.ZKNamespaceStateManager(205): Updating namespace state cache from node
path /hbase/namespace-state/TestNamespaceAuditor_regiontest with data:
NamespaceTableAndRegionInfo [name=TestNamespaceAuditor_regiontest,
tableRegionInfoMap={}]
{code}
ZKNamespaceStateManager received notification 1 millisecond later than the
receipt of DoNotRetryIOException
Please handle this scenario accordingly.
Basic quota support for namespaces
--
Key: HBASE-8410
URL: https://issues.apache.org/jira/browse/HBASE-8410
Project: HBase
Issue Type: Sub-task
Reporter: Francis Liu
Assignee: Vandana Ayyalasomayajula
Attachments: HBASE-8410_trunk_10.patch, HBASE-8410_trunk_10.patch,
HBASE-8410_trunk_11.patch, HBASE-8410_trunk_12.patch,
HBASE-8410_trunk_2.patch, HBASE-8410_trunk_3.patch, HBASE-8410_trunk_4.patch,
HBASE-8410_trunk_4.patch, HBASE-8410_trunk_5.patch, HBASE-8410_trunk_6.patch,
HBASE-8410_trunk_7.patch, HBASE-8410_trunk_8.patch, HBASE-8410_trunk_9.patch,
HBASE_8410.patch, HBASE_8410_1_trunk.patch
This task involves creating an observer which provides basic quota support to
namespaces in terms of (1) number of tables and (2) number of regions. The
quota support can be enabled by setting:
property
namehbase.coprocessor.region.classes/name
valueorg.apache.hadoop.hbase.namespace.NamespaceController/value
/property
property
namehbase.coprocessor.master.classes/name
valueorg.apache.hadoop.hbase.namespace.NamespaceController/value
/property
in the hbase-site.xml.
To add quotas to namespace, while creating namespace properties need to be
added.
Examples:
1. namespace_create 'ns1', {'hbase.namespace.quota.maxregion'='10'}
2. 1. namespace_create 'ns2', {'hbase.namespace.quota.maxtables'='2'},
{'hbase.namespace.quota.maxregion'='5'}
The quotas can be modified/added to namespace at any point of time.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-9360) Enable 0.94 - 0.96 replication to minimize upgrade down time
[ https://issues.apache.org/jira/browse/HBASE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875043#comment-13875043 ] Jeffrey Zhong commented on HBASE-9360: -- Good suggestions. Let me add a paragraph on this in the ref guide in upgrade replication. Enable 0.94 - 0.96 replication to minimize upgrade down time - Key: HBASE-9360 URL: https://issues.apache.org/jira/browse/HBASE-9360 Project: HBase Issue Type: Brainstorming Components: migration Affects Versions: 0.98.0, 0.96.0 Reporter: Jeffrey Zhong As we know 0.96 is a singularity release, as of today a 0.94 hbase user has to do in-place upgrade: make corresponding client changes, recompile client application code, fully shut down existing 0.94 hbase cluster, deploy 0.96 binary, run upgrade script and then start the upgraded cluster. You can image the down time will be extended if something is wrong in between. To minimize the down time, another possible way is to setup a secondary 0.96 cluster and then setup replication between the existing 0.94 cluster and the new 0.96 slave cluster. Once the 0.96 cluster is synced, a user can switch the traffic to the 0.96 cluster and decommission the old one. The ideal steps will be: 1) Setup a 0.96 cluster 2) Setup replication between a running 0.94 cluster to the newly created 0.96 cluster 3) Wait till they're in sync in replication 4) Starts duplicated writes to both 0.94 and 0.96 clusters(could stop relocation now) 5) Forward read traffic to the slave 0.96 cluster 6) After a certain period, stop writes to the original 0.94 cluster if everything is good and completes upgrade To get us there, there are two tasks: 1) Enable replication from 0.94 - 0.96 I've run the idea with [~jdcryans], [~devaraj] and [~ndimiduk]. Currently it seems the best approach is to build a very similar service or on top of https://github.com/NGDATA/hbase-indexer/tree/master/hbase-sep with support three commands replicateLogEntries, multi and delete. Inside the three commands, we just pass down the corresponding requests to the destination 0.96 cluster as a bridge. The reason to support the multi and delete is for CopyTable to copy data from a 0.94 cluster to a 0.96 one. The other approach is to provide limited support of 0.94 RPC protocol in 0.96. While an issue on this is that a 0.94 client needs to talk to zookeeper firstly before it can connect to a 0.96 region server. Therefore, we need a faked Zookeeper setup in front of a 0.96 cluster for a 0.94 client to connect. It may also pollute 0.96 code base with 0.94 RPC code. 2) To support writes to a 0.96 cluster and a 0.94 at the same time, we need to load both hbase clients into one single JVM using different class loader. Let me know if you think this is worth to do and any better approach we could take. Thanks! -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10289) Avoid random port usage by default JMX Server. Create Custome JMX server
[ https://issues.apache.org/jira/browse/HBASE-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875053#comment-13875053 ] stack commented on HBASE-10289: --- bq. The idea behind this patch is to give a option to user to control the ports used by JMX server. Great. These defines are only used in one place so I'd move them there rather than add them to HConstants: + /** Configuration key for rmi registry port */ + public static final String RMI_REGISTRY_PORT = .rmi.registry.port; + + /** Configuration key for rmi connector port */ + public static final String RMI_CONNECTOR_PORT = .rmi.connector.port; + + /** Configuration key for rmi registry ip */ + public static final String RMI_REGISTRY_IP = .rmi.registry.ip; + + /** Configuration key for rmi connector name */ + public static final String RMI_REGISTRY_CONNECTORNAME = .rmi.registry.connectorname; + + /** Default rmi registry ip value */ + public static final String RMI_REGISTRY_IP_DEFAULT = 127.0.0.1; JMXServer is missing an apache license (see adjacent .java files for how). I can add the audience annotation on commit. Class could do with a comment -- a synopsis of the comments you made above explaining this feature to me would do nicely. How does your server get started and shutdown? It should be embedded in Master and RegionServer? Avoid random port usage by default JMX Server. Create Custome JMX server Key: HBASE-10289 URL: https://issues.apache.org/jira/browse/HBASE-10289 Project: HBase Issue Type: Improvement Reporter: nijel Priority: Minor Attachments: HBASE-10289.patch If we enable JMX MBean server for HMaster or Region server through VM arguments, the process will use one random which we cannot configure. This can be a problem if that random port is configured for some other service. This issue can be avoided by supporting a custom JMX Server. The ports can be configured. If there is no ports configured, it will continue the same way as now. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-10370:
---
Affects Version/s: 0.98.0
+1 for 0.98
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Attachments: HBASE-10370-v1.diff, HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10322) Strip tags from KV while sending back to client on reads
[ https://issues.apache.org/jira/browse/HBASE-10322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875068#comment-13875068 ] Andrew Purtell commented on HBASE-10322: Agree. The goal is to prevent sensitive tags from going to clients who are not supposed to see them. This is blocking the 0.98 RC. Checking on a per cell basis is going to hurt performance. Massaging cell data on a per cell basis e.g. copying, will kill performance. We need some global decision per connection. Earlier we explored per-connection negotiation ideas on another JIRA but didn't come to a satisfactory resolution. Now we want to do the simplest thing possible. There is no need to handle tags in cell serialization for RPC. (Except! Replication! - Thanks [~anoop.hbase].) Cell ACLs and visibility expressions are shipped server side in operation attributes. Tag persistence with HFile v3 is all set. Tag persistence in the WAL uses WAL codecs which are only applied server side. We need an answer for replication though. My thinking is since we set up RPC for replication specially in the sink and source code, and replication is a server to server thing - or at least we can say replication is privileged - it should be ok to add a tag capable codec for replication, but have it not be the default. We can tell users that replication will be compatible between 0.96 and 0.98 as long as you don't use cell tags. If you do start using the 0.98 features which require cell tags, then your replication endpoints must all be upgrade to 0.98 first, and you must change a configuration setting. Strip tags from KV while sending back to client on reads Key: HBASE-10322 URL: https://issues.apache.org/jira/browse/HBASE-10322 Project: HBase Issue Type: Bug Affects Versions: 0.98.0 Reporter: Anoop Sam John Assignee: Anoop Sam John Priority: Blocker Fix For: 0.98.0, 0.99.0 Attachments: HBASE-10322.patch, HBASE-10322_V2.patch Right now we have some inconsistency wrt sending back tags on read. We do this in scan when using Java client(Codec based cell block encoding). But during a Get operation or when a pure PB based Scan comes we are not sending back the tags. So any of the below fix we have to do 1. Send back tags in missing cases also. But sending back visibility expression/ cell ACL is not correct. 2. Don't send back tags in any case. This will a problem when a tool like ExportTool use the scan to export the table data. We will miss exporting the cell visibility/ACL. 3. Send back tags based on some condition. It has to be per scan basis. Simplest way is pass some kind of attribute in Scan which says whether to send back tags or not. But believing some thing what scan specifies might not be correct IMO. Then comes the way of checking the user who is doing the scan. When a HBase super user doing the scan then only send back tags. So when a case comes like Export Tool's the execution should happen from a super user. So IMO we should go with #3. Patch coming soon. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10322) Strip tags from KV while sending back to client on reads
[ https://issues.apache.org/jira/browse/HBASE-10322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875069#comment-13875069 ] Andrew Purtell commented on HBASE-10322: Ping [~stack], [~jdcryans], [~ram_krish], see ^^^ Strip tags from KV while sending back to client on reads Key: HBASE-10322 URL: https://issues.apache.org/jira/browse/HBASE-10322 Project: HBase Issue Type: Bug Affects Versions: 0.98.0 Reporter: Anoop Sam John Assignee: Anoop Sam John Priority: Blocker Fix For: 0.98.0, 0.99.0 Attachments: HBASE-10322.patch, HBASE-10322_V2.patch Right now we have some inconsistency wrt sending back tags on read. We do this in scan when using Java client(Codec based cell block encoding). But during a Get operation or when a pure PB based Scan comes we are not sending back the tags. So any of the below fix we have to do 1. Send back tags in missing cases also. But sending back visibility expression/ cell ACL is not correct. 2. Don't send back tags in any case. This will a problem when a tool like ExportTool use the scan to export the table data. We will miss exporting the cell visibility/ACL. 3. Send back tags based on some condition. It has to be per scan basis. Simplest way is pass some kind of attribute in Scan which says whether to send back tags or not. But believing some thing what scan specifies might not be correct IMO. Then comes the way of checking the user who is doing the scan. When a HBase super user doing the scan then only send back tags. So when a case comes like Export Tool's the execution should happen from a super user. So IMO we should go with #3. Patch coming soon. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10370:
---
Attachment: 10370-v3.patch
Patch v3 closes the region and table in
TestSplitTransactionOnCluster#testSplitFailedCompactionAndSplit
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Attachments: 10370-v3.patch, HBASE-10370-v1.diff, HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10370:
---
Fix Version/s: 0.99.0
0.98.0
Hadoop Flags: Reviewed
Integrated to 0.98 and trunk.
Thanks for the patch, Shaohui.
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.99.0
Attachments: 10370-v3.patch, HBASE-10370-v1.diff, HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10123) Change default ports; move them out of linux ephemeral port range
[
https://issues.apache.org/jira/browse/HBASE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875108#comment-13875108
]
Hadoop QA commented on HBASE-10123:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12623685/hbase-10123.v4.patch
against trunk revision .
ATTACHMENT ID: 12623685
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8460//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8460//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8460//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8460//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8460//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8460//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8460//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8460//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8460//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8460//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8460//console
This message is automatically generated.
Change default ports; move them out of linux ephemeral port range
-
Key: HBASE-10123
URL: https://issues.apache.org/jira/browse/HBASE-10123
Project: HBase
Issue Type: Bug
Affects Versions: 0.96.1.1
Reporter: stack
Assignee: Jonathan Hsieh
Priority: Critical
Fix For: 0.99.0
Attachments: hbase-10123.patch, hbase-10123.v2.patch,
hbase-10123.v3.patch, hbase-10123.v4.patch
Our defaults clash w/ the range linux assigns itself for creating come-and-go
ephemeral ports; likely in our history we've clashed w/ a random, short-lived
process. While easy to change the defaults, we should just ship w/ defaults
that make sense. We could host ourselves up into the 7 or 8k range.
See http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875118#comment-13875118
]
Hadoop QA commented on HBASE-10370:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12623704/10370-v3.patch
against trunk revision .
ATTACHMENT ID: 12623704
{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:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8462//console
This message is automatically generated.
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-10370:
--
Attachment: 10370v2.096.txt
What I applied to 0.96 (no unit test -- it failed apply). Thanks [~liushaohui]
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-10370:
--
Fix Version/s: 0.96.2
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10375) hbase-default.xml hbase.status.multicast.address.port does not match code
[
https://issues.apache.org/jira/browse/HBASE-10375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875126#comment-13875126
]
Andrew Purtell commented on HBASE-10375:
60100 or 16100 ?
hbase-default.xml hbase.status.multicast.address.port does not match code
-
Key: HBASE-10375
URL: https://issues.apache.org/jira/browse/HBASE-10375
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.0, 0.99.0, 0.96.1.1
Reporter: Jonathan Hsieh
In hbase-default.xml
{code}
+ property
+namehbase.status.multicast.address.port/name
+value6100/value
+description
+ Multicast port to use for the status publication by multicast.
+/description
+ /property
{code}
In HConstants it was 60100.
{code}
public static final String STATUS_MULTICAST_PORT =
hbase.status.multicast.port;
public static final int DEFAULT_STATUS_MULTICAST_PORT = 16100;
{code}
(it was 60100 in the code for 0.96 and 0.98.)
I lean towards going with the code as opposed to the config file.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10156) Fix up the HBASE-8755 slowdown when low contention
[ https://issues.apache.org/jira/browse/HBASE-10156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875129#comment-13875129 ] stack commented on HBASE-10156: --- Looking for a review please. Does some cleanup of HLog, gets us back some of the perf we lost when we moved to new thread model (hbase-8755) when low contention. As side benefit, it improves perf when high contention. Downside is refactor of critical FSHLog class. Am testing on cluster over here meantime. Fix up the HBASE-8755 slowdown when low contention -- Key: HBASE-10156 URL: https://issues.apache.org/jira/browse/HBASE-10156 Project: HBase Issue Type: Sub-task Components: wal Reporter: stack Assignee: stack Attachments: 10156.txt, 10156v10.txt, 10156v11.txt, 10156v12.txt, 10156v12.txt, 10156v13.txt, 10156v16.txt, 10156v17.txt, 10156v18.txt, 10156v2.txt, 10156v3.txt, 10156v4.txt, 10156v5.txt, 10156v6.txt, 10156v7.txt, 10156v9.txt, Disrupting.java HBASE-8755 slows our writes when only a few clients. Fix. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10375) hbase-default.xml hbase.status.multicast.address.port does not match code
[
https://issues.apache.org/jira/browse/HBASE-10375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875131#comment-13875131
]
Jonathan Hsieh commented on HBASE-10375:
I committed HBASE-10123 to trunk only so i believe:
* all should say hbase.status.multicast.port instead of
hbase.status.multicast.address.port
* 0.96/0.98 should be 60100
* trunk should be 16100
We should get [~nkeywal] to take a quick look to verify this.
hbase-default.xml hbase.status.multicast.address.port does not match code
-
Key: HBASE-10375
URL: https://issues.apache.org/jira/browse/HBASE-10375
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.0, 0.99.0, 0.96.1.1
Reporter: Jonathan Hsieh
In hbase-default.xml
{code}
+ property
+namehbase.status.multicast.address.port/name
+value6100/value
+description
+ Multicast port to use for the status publication by multicast.
+/description
+ /property
{code}
In HConstants it was 60100.
{code}
public static final String STATUS_MULTICAST_PORT =
hbase.status.multicast.port;
public static final int DEFAULT_STATUS_MULTICAST_PORT = 16100;
{code}
(it was 60100 in the code for 0.96 and 0.98.)
I lean towards going with the code as opposed to the config file.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10030) [JDK8] Erasure of PoolMap#remove(K,V) conflicts with superclass method
[ https://issues.apache.org/jira/browse/HBASE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875132#comment-13875132 ] Andrew Purtell commented on HBASE-10030: bq. Java version: 1.8.0-ea, vendor: Oracle Corporation Ok, I am sorry, I have not adequately explained what we did here. We deprecated the old method but did not remove it. Therefore at some point we can kill the conflicting method, I guess we can do this in trunk now that 0.98 is branched, and *then* we can compile with JDK 8. [JDK8] Erasure of PoolMap#remove(K,V) conflicts with superclass method -- Key: HBASE-10030 URL: https://issues.apache.org/jira/browse/HBASE-10030 Project: HBase Issue Type: Bug Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Trivial Fix For: 0.98.0 Attachments: 10030.patch On JDK 8, the erasure of PoolMap#remove(K,V) conflicts with superclass method remove(Object,Object). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10322) Strip tags from KV while sending back to client on reads
[ https://issues.apache.org/jira/browse/HBASE-10322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875139#comment-13875139 ] stack commented on HBASE-10322: --- Sounds reasonable Andrew, what you say about replication ([~jdcryans] is not around -- he is off in exotic locations again!). Is there a patch to review yet? Strip tags from KV while sending back to client on reads Key: HBASE-10322 URL: https://issues.apache.org/jira/browse/HBASE-10322 Project: HBase Issue Type: Bug Affects Versions: 0.98.0 Reporter: Anoop Sam John Assignee: Anoop Sam John Priority: Blocker Fix For: 0.98.0, 0.99.0 Attachments: HBASE-10322.patch, HBASE-10322_V2.patch Right now we have some inconsistency wrt sending back tags on read. We do this in scan when using Java client(Codec based cell block encoding). But during a Get operation or when a pure PB based Scan comes we are not sending back the tags. So any of the below fix we have to do 1. Send back tags in missing cases also. But sending back visibility expression/ cell ACL is not correct. 2. Don't send back tags in any case. This will a problem when a tool like ExportTool use the scan to export the table data. We will miss exporting the cell visibility/ACL. 3. Send back tags based on some condition. It has to be per scan basis. Simplest way is pass some kind of attribute in Scan which says whether to send back tags or not. But believing some thing what scan specifies might not be correct IMO. Then comes the way of checking the user who is doing the scan. When a HBase super user doing the scan then only send back tags. So when a case comes like Export Tool's the execution should happen from a super user. So IMO we should go with #3. Patch coming soon. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (HBASE-10030) [JDK8] Erasure of PoolMap#remove(K,V) conflicts with superclass method
[ https://issues.apache.org/jira/browse/HBASE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875132#comment-13875132 ] Andrew Purtell edited comment on HBASE-10030 at 1/17/14 7:18 PM: - bq. Java version: 1.8.0-ea, vendor: Oracle Corporation Ok, I am sorry, I have not adequately explained what we did here. We deprecated the old method but did not remove it. Therefore at some point we can kill the conflicting method, I guess we can do this in trunk now that 0.98 is branched, and *then* we can compile with JDK 8. Edit: Also, above, I forgot I have this removal applied privately to the branch I use for JDK 8 stuff. Sorry again. was (Author: apurtell): bq. Java version: 1.8.0-ea, vendor: Oracle Corporation Ok, I am sorry, I have not adequately explained what we did here. We deprecated the old method but did not remove it. Therefore at some point we can kill the conflicting method, I guess we can do this in trunk now that 0.98 is branched, and *then* we can compile with JDK 8. [JDK8] Erasure of PoolMap#remove(K,V) conflicts with superclass method -- Key: HBASE-10030 URL: https://issues.apache.org/jira/browse/HBASE-10030 Project: HBase Issue Type: Bug Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Trivial Fix For: 0.98.0 Attachments: 10030.patch On JDK 8, the erasure of PoolMap#remove(K,V) conflicts with superclass method remove(Object,Object). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10030) [JDK8] Erasure of PoolMap#remove(K,V) conflicts with superclass method
[ https://issues.apache.org/jira/browse/HBASE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875137#comment-13875137 ] Andrew Purtell commented on HBASE-10030: An alternative for trunk is we can just kill PoolMap as [~lhofhansl] says above. [JDK8] Erasure of PoolMap#remove(K,V) conflicts with superclass method -- Key: HBASE-10030 URL: https://issues.apache.org/jira/browse/HBASE-10030 Project: HBase Issue Type: Bug Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Trivial Fix For: 0.98.0 Attachments: 10030.patch On JDK 8, the erasure of PoolMap#remove(K,V) conflicts with superclass method remove(Object,Object). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10322) Strip tags from KV while sending back to client on reads
[ https://issues.apache.org/jira/browse/HBASE-10322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875141#comment-13875141 ] Andrew Purtell commented on HBASE-10322: bq. Is there a patch to review yet? There will be something shortly after we agree this is the way to go. Sounds like it. Soon, then. Strip tags from KV while sending back to client on reads Key: HBASE-10322 URL: https://issues.apache.org/jira/browse/HBASE-10322 Project: HBase Issue Type: Bug Affects Versions: 0.98.0 Reporter: Anoop Sam John Assignee: Anoop Sam John Priority: Blocker Fix For: 0.98.0, 0.99.0 Attachments: HBASE-10322.patch, HBASE-10322_V2.patch Right now we have some inconsistency wrt sending back tags on read. We do this in scan when using Java client(Codec based cell block encoding). But during a Get operation or when a pure PB based Scan comes we are not sending back the tags. So any of the below fix we have to do 1. Send back tags in missing cases also. But sending back visibility expression/ cell ACL is not correct. 2. Don't send back tags in any case. This will a problem when a tool like ExportTool use the scan to export the table data. We will miss exporting the cell visibility/ACL. 3. Send back tags based on some condition. It has to be per scan basis. Simplest way is pass some kind of attribute in Scan which says whether to send back tags or not. But believing some thing what scan specifies might not be correct IMO. Then comes the way of checking the user who is doing the scan. When a HBase super user doing the scan then only send back tags. So when a case comes like Export Tool's the execution should happen from a super user. So IMO we should go with #3. Patch coming soon. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875142#comment-13875142
]
Hadoop QA commented on HBASE-10370:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12623710/10370v2.096.txt
against trunk revision .
ATTACHMENT ID: 12623710
{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/8463//console
This message is automatically generated.
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10030) [JDK8] Erasure of PoolMap#remove(K,V) conflicts with superclass method
[ https://issues.apache.org/jira/browse/HBASE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875151#comment-13875151 ] Eric Charles commented on HBASE-10030: -- HBASE-10327.patch in HBASE-10327 is the removal of that deprecated method which is not used in trunk. I think you could apply HBASE-10327.patch and it would be ok (Would be good to compile with jdk8 because hbase runs fine with jdk8) [JDK8] Erasure of PoolMap#remove(K,V) conflicts with superclass method -- Key: HBASE-10030 URL: https://issues.apache.org/jira/browse/HBASE-10030 Project: HBase Issue Type: Bug Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Trivial Fix For: 0.98.0 Attachments: 10030.patch On JDK 8, the erasure of PoolMap#remove(K,V) conflicts with superclass method remove(Object,Object). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10327) Remove remove(K, V) from type PoolMapK,V
[ https://issues.apache.org/jira/browse/HBASE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-10327: --- Summary: Remove remove(K, V) from type PoolMapK,V (was: remove(K, V) of type PoolMapK,V has the same erasure) Remove remove(K, V) from type PoolMapK,V -- Key: HBASE-10327 URL: https://issues.apache.org/jira/browse/HBASE-10327 Project: HBase Issue Type: Bug Affects Versions: 0.99.0 Reporter: Eric Charles Assignee: Eric Charles Attachments: HBASE-10327.patch I keep getting red cross in my eclipse, whatever the jdk (jdk6, jdk7, jdk8) Name clash: The method remove(K, V) of type PoolMapK,V has the same erasure as remove(Object, Object) of type MapK,V but does not override it maybe related to HBASE-10030 The solution I have is simply removing the deprecated method, and everything is fine. I am not sure of the backwards compatibility here. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10030) [JDK8] Erasure of PoolMap#remove(K,V) conflicts with superclass method
[ https://issues.apache.org/jira/browse/HBASE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875153#comment-13875153 ] Andrew Purtell commented on HBASE-10030: bq. I think you could apply HBASE-10327.patch and it would be ok Thanks for the reminder. Let's repurpose that one. [JDK8] Erasure of PoolMap#remove(K,V) conflicts with superclass method -- Key: HBASE-10030 URL: https://issues.apache.org/jira/browse/HBASE-10030 Project: HBase Issue Type: Bug Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Trivial Fix For: 0.98.0 Attachments: 10030.patch On JDK 8, the erasure of PoolMap#remove(K,V) conflicts with superclass method remove(Object,Object). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Reopened] (HBASE-10327) remove(K, V) of type PoolMapK,V has the same erasure
[ https://issues.apache.org/jira/browse/HBASE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell reopened HBASE-10327: Assignee: Eric Charles remove(K, V) of type PoolMapK,V has the same erasure -- Key: HBASE-10327 URL: https://issues.apache.org/jira/browse/HBASE-10327 Project: HBase Issue Type: Bug Affects Versions: 0.99.0 Reporter: Eric Charles Assignee: Eric Charles Attachments: HBASE-10327.patch I keep getting red cross in my eclipse, whatever the jdk (jdk6, jdk7, jdk8) Name clash: The method remove(K, V) of type PoolMapK,V has the same erasure as remove(Object, Object) of type MapK,V but does not override it maybe related to HBASE-10030 The solution I have is simply removing the deprecated method, and everything is fine. I am not sure of the backwards compatibility here. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10327) Remove remove(K, V) from type PoolMapK,V
[ https://issues.apache.org/jira/browse/HBASE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875159#comment-13875159 ] Andrew Purtell commented on HBASE-10327: We deprecated the offending method with HBASE-10030, which will be in 0.98, and now need to remove it on trunk. Will do so by committing this patch to trunk shortly unless objection. Remove remove(K, V) from type PoolMapK,V -- Key: HBASE-10327 URL: https://issues.apache.org/jira/browse/HBASE-10327 Project: HBase Issue Type: Bug Affects Versions: 0.99.0 Reporter: Eric Charles Assignee: Eric Charles Attachments: HBASE-10327.patch I keep getting red cross in my eclipse, whatever the jdk (jdk6, jdk7, jdk8) Name clash: The method remove(K, V) of type PoolMapK,V has the same erasure as remove(Object, Object) of type MapK,V but does not override it maybe related to HBASE-10030 The solution I have is simply removing the deprecated method, and everything is fine. I am not sure of the backwards compatibility here. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10346) Add Documentation for stateless scanner
[ https://issues.apache.org/jira/browse/HBASE-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vandana Ayyalasomayajula updated HBASE-10346: - Attachment: HBASE-10346.1.patch Add Documentation for stateless scanner --- Key: HBASE-10346 URL: https://issues.apache.org/jira/browse/HBASE-10346 Project: HBase Issue Type: Improvement Components: REST Reporter: Vandana Ayyalasomayajula Assignee: Vandana Ayyalasomayajula Priority: Minor Fix For: 0.98.0, 0.99.0 Attachments: HBASE-10346.0.patch, HBASE-10346.1.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10372) TestHBaseFsck#testSplitDaughtersNotInMeta often fails
[
https://issues.apache.org/jira/browse/HBASE-10372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875163#comment-13875163
]
Andrew Purtell commented on HBASE-10372:
This is only happening on builds.apache.org ? Not saying it's not a problem,
just that I haven't seen this locally on three boxes running the unit tests
continuously.
TestHBaseFsck#testSplitDaughtersNotInMeta often fails
-
Key: HBASE-10372
URL: https://issues.apache.org/jira/browse/HBASE-10372
Project: HBase
Issue Type: Test
Reporter: Ted Yu
Attachments: 10372-testSplitDaughtersNotInMeta-output.html
This test fails quite often.
Here are some examples:
https://builds.apache.org/job/HBase-0.98/88/
https://builds.apache.org/job/HBase-0.98/89/
This assertion fails:
{code}
assertNotNull(HRegionInfo.getHRegionInfo(result));
{code}
the split hbase:meta entry didn't have corresponding HRegionInfo.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10372) TestHBaseFsck#testSplitDaughtersNotInMeta often fails
[
https://issues.apache.org/jira/browse/HBASE-10372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875164#comment-13875164
]
Andrew Purtell commented on HBASE-10372:
These days I'm inclined to close any issue opened from a builds.apache.org
result that cannot be reproduced locally as Cannot Reproduce.
TestHBaseFsck#testSplitDaughtersNotInMeta often fails
-
Key: HBASE-10372
URL: https://issues.apache.org/jira/browse/HBASE-10372
Project: HBase
Issue Type: Test
Reporter: Ted Yu
Attachments: 10372-testSplitDaughtersNotInMeta-output.html
This test fails quite often.
Here are some examples:
https://builds.apache.org/job/HBase-0.98/88/
https://builds.apache.org/job/HBase-0.98/89/
This assertion fails:
{code}
assertNotNull(HRegionInfo.getHRegionInfo(result));
{code}
the split hbase:meta entry didn't have corresponding HRegionInfo.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-9845) Add MR support for cell ACLs
[ https://issues.apache.org/jira/browse/HBASE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875168#comment-13875168 ] Andrew Purtell commented on HBASE-9845: --- Looks like this got missed, working on it. Add MR support for cell ACLs Key: HBASE-9845 URL: https://issues.apache.org/jira/browse/HBASE-9845 Project: HBase Issue Type: Improvement Affects Versions: 0.98.0 Reporter: Andrew Purtell Assignee: Andrew Purtell Fix For: 0.98.0 We should support adding cell ACLs through TableOutputFormat and HFileOutputFormat. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10349) Table became unusable when master balanced its region after table was dropped
[
https://issues.apache.org/jira/browse/HBASE-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875169#comment-13875169
]
Hadoop QA commented on HBASE-10349:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12623695/hbase-10349_v2.patch
against trunk revision .
ATTACHMENT ID: 12623695
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8461//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8461//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8461//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8461//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8461//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8461//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8461//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8461//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8461//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8461//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8461//console
This message is automatically generated.
Table became unusable when master balanced its region after table was dropped
-
Key: HBASE-10349
URL: https://issues.apache.org/jira/browse/HBASE-10349
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.0
Reporter: Ted Yu
Assignee: Jimmy Xiang
Fix For: 0.98.0, 0.99.0
Attachments:
10349-hadoop-hdfs-namenode-hor11n14.gq1.ygridcore.net.zip, 10349-output.log,
10349-v1.txt, 10349-v2.txt, HBASE-10349-meta-test-and-debug.patch,
hbase-10349.patch, hbase-10349_v2.patch,
hbase-hbase-master-hor15n05.gq1.ygridcore.net.log.tar.gz
0.98 was used.
This was sequence of events:
create 'tablethree_mod'
snapshot 'tablethree_mod', 'snapshot_tablethree_mod'
disable 'tablethree_mod'
2014-01-15 09:34:51,749 restore_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:35:07,210 enable 'tablethree_mod'
2014-01-15 09:35:46,134 delete_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:41:42,210 disable 'tablethree_mod'
2014-01-15 09:41:43,610 drop 'tablethree_mod'
create 'tablethree_mod'
For the last table creation request:
{code}
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'create 'tablethree_mod',
{NAME = 'f1', VERSIONS = 3}
,
{NAME = 'f2', VERSIONS = 3}
,
{NAME = 'f3', VERSIONS = 3}
'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'exists 'tablethree_mod''
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'0', 'f1:q1', 'value-0', 10'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'1', 'f1:q1', 'value-1', 20'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'2', 'f2:q2', 'value-2', 30'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put
[jira] [Updated] (HBASE-10372) TestHBaseFsck#testSplitDaughtersNotInMeta often fails
[
https://issues.apache.org/jira/browse/HBASE-10372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-10372:
---
Fix Version/s: 0.99.0
0.98.0
Ok, I will mark this with a fix version for 0.98.0 but if at RC time there's no
patch on the issue or this cannot be reproduced locally, I will do the above.
TestHBaseFsck#testSplitDaughtersNotInMeta often fails
-
Key: HBASE-10372
URL: https://issues.apache.org/jira/browse/HBASE-10372
Project: HBase
Issue Type: Test
Reporter: Ted Yu
Fix For: 0.98.0, 0.99.0
Attachments: 10372-testSplitDaughtersNotInMeta-output.html
This test fails quite often.
Here are some examples:
https://builds.apache.org/job/HBase-0.98/88/
https://builds.apache.org/job/HBase-0.98/89/
This assertion fails:
{code}
assertNotNull(HRegionInfo.getHRegionInfo(result));
{code}
the split hbase:meta entry didn't have corresponding HRegionInfo.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10372) TestHBaseFsck#testSplitDaughtersNotInMeta often fails
[
https://issues.apache.org/jira/browse/HBASE-10372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875173#comment-13875173
]
Ted Yu commented on HBASE-10372:
The above did happen on Apache Jenkins.
I am running the test locally.
Will resolve if cannot reproduce.
TestHBaseFsck#testSplitDaughtersNotInMeta often fails
-
Key: HBASE-10372
URL: https://issues.apache.org/jira/browse/HBASE-10372
Project: HBase
Issue Type: Test
Reporter: Ted Yu
Fix For: 0.98.0, 0.99.0
Attachments: 10372-testSplitDaughtersNotInMeta-output.html
This test fails quite often.
Here are some examples:
https://builds.apache.org/job/HBase-0.98/88/
https://builds.apache.org/job/HBase-0.98/89/
This assertion fails:
{code}
assertNotNull(HRegionInfo.getHRegionInfo(result));
{code}
the split hbase:meta entry didn't have corresponding HRegionInfo.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10374) add jemalloc into the choice of memstore allocation
[ https://issues.apache.org/jira/browse/HBASE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875179#comment-13875179 ] Andrew Purtell commented on HBASE-10374: I found it here: http://netty.io/4.0/api/io/netty/buffer/ByteBufAllocator.html add jemalloc into the choice of memstore allocation Key: HBASE-10374 URL: https://issues.apache.org/jira/browse/HBASE-10374 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.96.1.1 Reporter: Bing Jiang Priority: Minor https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead introduced that Netty used jemalloc to gain benefits from GC. It can be a good choice for memstore block allocation. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10374) add jemalloc into the choice of memstore allocation
[ https://issues.apache.org/jira/browse/HBASE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875181#comment-13875181 ] Andrew Purtell commented on HBASE-10374: Someone should try pulling in netty4 while excluding earlier versions to see what happens. I bet it will be a mess :-) given our dependencies on Jetty 6 and ZooKeeper. add jemalloc into the choice of memstore allocation Key: HBASE-10374 URL: https://issues.apache.org/jira/browse/HBASE-10374 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.96.1.1 Reporter: Bing Jiang Priority: Minor https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead introduced that Netty used jemalloc to gain benefits from GC. It can be a good choice for memstore block allocation. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10349) Table became unusable when master balanced its region after table was dropped
[
https://issues.apache.org/jira/browse/HBASE-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875188#comment-13875188
]
Matteo Bertozzi commented on HBASE-10349:
-
+1 on jimmy v2 for me.
(it will be nice also having the MetaEditor.overwriteRegions test and the add
regions debug committed, but I guess i can create another jira for them)
Table became unusable when master balanced its region after table was dropped
-
Key: HBASE-10349
URL: https://issues.apache.org/jira/browse/HBASE-10349
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.0
Reporter: Ted Yu
Assignee: Jimmy Xiang
Fix For: 0.98.0, 0.99.0
Attachments:
10349-hadoop-hdfs-namenode-hor11n14.gq1.ygridcore.net.zip, 10349-output.log,
10349-v1.txt, 10349-v2.txt, HBASE-10349-meta-test-and-debug.patch,
hbase-10349.patch, hbase-10349_v2.patch,
hbase-hbase-master-hor15n05.gq1.ygridcore.net.log.tar.gz
0.98 was used.
This was sequence of events:
create 'tablethree_mod'
snapshot 'tablethree_mod', 'snapshot_tablethree_mod'
disable 'tablethree_mod'
2014-01-15 09:34:51,749 restore_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:35:07,210 enable 'tablethree_mod'
2014-01-15 09:35:46,134 delete_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:41:42,210 disable 'tablethree_mod'
2014-01-15 09:41:43,610 drop 'tablethree_mod'
create 'tablethree_mod'
For the last table creation request:
{code}
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'create 'tablethree_mod',
{NAME = 'f1', VERSIONS = 3}
,
{NAME = 'f2', VERSIONS = 3}
,
{NAME = 'f3', VERSIONS = 3}
'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'exists 'tablethree_mod''
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'0', 'f1:q1', 'value-0', 10'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'1', 'f1:q1', 'value-1', 20'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'2', 'f2:q2', 'value-2', 30'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'3', 'f3:q3', 'value-3', 40'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'4', 'f3:q3', 'value-4', 50'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO|Done writing commands to
file. Will execute them now.
2014-01-15 10:03:53,000|beaver.machine|INFO|RUNNING: /usr/lib/hbase/bin/hbase
shell /grid/0/tmp/hwqe/artifacts/tmp-471142
2014-01-15 10:03:55,878|beaver.machine|INFO|2014-01-15 10:03:55,878 INFO
[main] Configuration.deprecation: hadoop.native.lib is deprecated. Instead,
use io.native.lib.available
2014-01-15 10:03:57,283|beaver.machine|INFO|2014-01-15 10:03:57,283 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,669|beaver.machine|INFO|2014-01-15 10:03:57,669 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,720|beaver.machine|INFO|2014-01-15 10:03:57,720 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,997|beaver.machine|INFO|
2014-01-15 10:03:57,997|beaver.machine|INFO|ERROR: Table already exists:
tablethree_mod!
2014-01-15 10:03:57,997|beaver.machine|INFO|
{code}
This was an intermittent issue after using Snapshots, a table is not properly
dropped / and not able to properly re-create with the same name. And a
HRegion is empty or null Error occurs. (When you try to drop the table it
says it does not exist, and when you try to create the table it says that it
does already exist).
{code}
2014-01-15 10:04:02,462|beaver.machine|INFO|ERROR: HRegionInfo was null or
empty in hbase:meta, row=keyvalues=
{tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:seqnumDuringOpen/1389778905355/Put/vlen=8/mvcc=0,
tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:server/1389778905355/Put/vlen=32/mvcc=0,
tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:serverstartcode/1389778905355/Put/vlen=8/mvcc=0}
{code}
Thanks to Huned who discovered this issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10371) Compact create empty hfile, then select this file for compaction and create empty hfile and over again.
[
https://issues.apache.org/jira/browse/HBASE-10371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875201#comment-13875201
]
Andrew Purtell commented on HBASE-10371:
+1 for 0.98
Compact create empty hfile, then select this file for compaction and create
empty hfile and over again.
---
Key: HBASE-10371
URL: https://issues.apache.org/jira/browse/HBASE-10371
Project: HBase
Issue Type: Bug
Reporter: binlijin
Attachments: HBASE-10371-94.patch, HBASE-10371-trunk-2.patch,
HBASE-10371-trunk.patch
(1) Select HFile for compaction
{code}
2014-01-16 01:01:25,111 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection: Deleting
the expired store file by compaction:
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/f3e38d10d579420494079e17a2557f0b
whose maxTimeStamp is -1 while the max expired timestamp is 1389632485111
{code}
(2) Compact
{code}
2014-01-16 01:01:26,042 DEBUG org.apache.hadoop.hbase.regionserver.Compactor:
Compacting
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/f3e38d10d579420494079e17a2557f0b,
keycount=0, bloomtype=NONE, size=534, encoding=NONE
2014-01-16 01:01:26,045 DEBUG org.apache.hadoop.hbase.util.FSUtils: Creating
file=hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/.tmp/40de5d79f80e4fb197e409fb99ab0fd8
with permission=rwxrwxrwx
2014-01-16 01:01:26,076 INFO org.apache.hadoop.hbase.regionserver.Store:
Renaming compacted file at
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/.tmp/40de5d79f80e4fb197e409fb99ab0fd8
to
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8
2014-01-16 01:01:26,142 INFO org.apache.hadoop.hbase.regionserver.Store:
Completed compaction of 1 file(s) in a of
storagetable,01:,1369377609136.7d8941661904fb99a41f79a1fce47767. into
40de5d79f80e4fb197e409fb99ab0fd8, size=534; total size for store is 399.0 M
2014-01-16 01:01:26,142 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactionRequest: completed
compaction:
regionName=storagetable,01:,1369377609136.7d8941661904fb99a41f79a1fce47767.,
storeName=a, fileCount=1, fileSize=534, priority=16, time=18280340606333745;
duration=0sec
{code}
(3) Select HFile for compaction
{code}
2014-01-16 03:48:05,120 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection: Deleting
the expired store file by compaction:
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8
whose maxTimeStamp is -1 while the max expired timestamp is 1389642485120
{code}
(4) Compact
{code}
2014-01-16 03:50:17,731 DEBUG org.apache.hadoop.hbase.regionserver.Compactor:
Compacting
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8,
keycount=0, bloomtype=NONE, size=534, encoding=NONE
2014-01-16 03:50:17,732 DEBUG org.apache.hadoop.hbase.util.FSUtils: Creating
file=hdfs://dump002002.cm6:9000/hbase-0.90
{code}
...
this loop for ever.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10371) Compact create empty hfile, then select this file for compaction and create empty hfile and over again.
[
https://issues.apache.org/jira/browse/HBASE-10371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875210#comment-13875210
]
Lars Hofhansl commented on HBASE-10371:
---
lgtm
Compact create empty hfile, then select this file for compaction and create
empty hfile and over again.
---
Key: HBASE-10371
URL: https://issues.apache.org/jira/browse/HBASE-10371
Project: HBase
Issue Type: Bug
Reporter: binlijin
Attachments: HBASE-10371-94.patch, HBASE-10371-trunk-2.patch,
HBASE-10371-trunk.patch
(1) Select HFile for compaction
{code}
2014-01-16 01:01:25,111 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection: Deleting
the expired store file by compaction:
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/f3e38d10d579420494079e17a2557f0b
whose maxTimeStamp is -1 while the max expired timestamp is 1389632485111
{code}
(2) Compact
{code}
2014-01-16 01:01:26,042 DEBUG org.apache.hadoop.hbase.regionserver.Compactor:
Compacting
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/f3e38d10d579420494079e17a2557f0b,
keycount=0, bloomtype=NONE, size=534, encoding=NONE
2014-01-16 01:01:26,045 DEBUG org.apache.hadoop.hbase.util.FSUtils: Creating
file=hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/.tmp/40de5d79f80e4fb197e409fb99ab0fd8
with permission=rwxrwxrwx
2014-01-16 01:01:26,076 INFO org.apache.hadoop.hbase.regionserver.Store:
Renaming compacted file at
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/.tmp/40de5d79f80e4fb197e409fb99ab0fd8
to
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8
2014-01-16 01:01:26,142 INFO org.apache.hadoop.hbase.regionserver.Store:
Completed compaction of 1 file(s) in a of
storagetable,01:,1369377609136.7d8941661904fb99a41f79a1fce47767. into
40de5d79f80e4fb197e409fb99ab0fd8, size=534; total size for store is 399.0 M
2014-01-16 01:01:26,142 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactionRequest: completed
compaction:
regionName=storagetable,01:,1369377609136.7d8941661904fb99a41f79a1fce47767.,
storeName=a, fileCount=1, fileSize=534, priority=16, time=18280340606333745;
duration=0sec
{code}
(3) Select HFile for compaction
{code}
2014-01-16 03:48:05,120 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection: Deleting
the expired store file by compaction:
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8
whose maxTimeStamp is -1 while the max expired timestamp is 1389642485120
{code}
(4) Compact
{code}
2014-01-16 03:50:17,731 DEBUG org.apache.hadoop.hbase.regionserver.Compactor:
Compacting
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8,
keycount=0, bloomtype=NONE, size=534, encoding=NONE
2014-01-16 03:50:17,732 DEBUG org.apache.hadoop.hbase.util.FSUtils: Creating
file=hdfs://dump002002.cm6:9000/hbase-0.90
{code}
...
this loop for ever.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10249) Intermittent TestReplicationSyncUpTool failure
[ https://issues.apache.org/jira/browse/HBASE-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875217#comment-13875217 ] Lars Hofhansl commented on HBASE-10249: --- you gonna commit [~jdcryans]? Intermittent TestReplicationSyncUpTool failure -- Key: HBASE-10249 URL: https://issues.apache.org/jira/browse/HBASE-10249 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Jean-Daniel Cryans Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17 Attachments: HBASE-10249-0.94-v0.patch, HBASE-10249-0.94-v1.patch, HBASE-10249-trunk-v0.patch, HBASE-10249-trunk-v1.patch New issue to keep track of this. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10123) Change default ports; move them out of linux ephemeral port range
[ https://issues.apache.org/jira/browse/HBASE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875229#comment-13875229 ] Hudson commented on HBASE-10123: SUCCESS: Integrated in HBase-TRUNK #4830 (See [https://builds.apache.org/job/HBase-TRUNK/4830/]) HBASE-10123 Change default ports; move them out of linux ephemeral port range (jmhsieh: rev 1559200) * /hbase/trunk/bin/local-master-backup.sh * /hbase/trunk/hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestClientNoCluster.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java * /hbase/trunk/hbase-common/src/main/resources/hbase-default.xml * /hbase/trunk/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/master/BackupMasterStatusTmpl.jamon * /hbase/trunk/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/RSStatusTmpl.jamon * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/LocalHBaseCluster.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * /hbase/trunk/src/main/docbkx/configuration.xml * /hbase/trunk/src/main/docbkx/troubleshooting.xml Change default ports; move them out of linux ephemeral port range - Key: HBASE-10123 URL: https://issues.apache.org/jira/browse/HBASE-10123 Project: HBase Issue Type: Bug Affects Versions: 0.96.1.1 Reporter: stack Assignee: Jonathan Hsieh Priority: Critical Fix For: 0.99.0 Attachments: hbase-10123.patch, hbase-10123.v2.patch, hbase-10123.v3.patch, hbase-10123.v4.patch Our defaults clash w/ the range linux assigns itself for creating come-and-go ephemeral ports; likely in our history we've clashed w/ a random, short-lived process. While easy to change the defaults, we should just ship w/ defaults that make sense. We could host ourselves up into the 7 or 8k range. See http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10371) Compact create empty hfile, then select this file for compaction and create empty hfile and over again.
[
https://issues.apache.org/jira/browse/HBASE-10371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10371:
---
Status: Patch Available (was: Open)
Compact create empty hfile, then select this file for compaction and create
empty hfile and over again.
---
Key: HBASE-10371
URL: https://issues.apache.org/jira/browse/HBASE-10371
Project: HBase
Issue Type: Bug
Reporter: binlijin
Attachments: HBASE-10371-94.patch, HBASE-10371-trunk-2.patch,
HBASE-10371-trunk.patch
(1) Select HFile for compaction
{code}
2014-01-16 01:01:25,111 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection: Deleting
the expired store file by compaction:
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/f3e38d10d579420494079e17a2557f0b
whose maxTimeStamp is -1 while the max expired timestamp is 1389632485111
{code}
(2) Compact
{code}
2014-01-16 01:01:26,042 DEBUG org.apache.hadoop.hbase.regionserver.Compactor:
Compacting
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/f3e38d10d579420494079e17a2557f0b,
keycount=0, bloomtype=NONE, size=534, encoding=NONE
2014-01-16 01:01:26,045 DEBUG org.apache.hadoop.hbase.util.FSUtils: Creating
file=hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/.tmp/40de5d79f80e4fb197e409fb99ab0fd8
with permission=rwxrwxrwx
2014-01-16 01:01:26,076 INFO org.apache.hadoop.hbase.regionserver.Store:
Renaming compacted file at
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/.tmp/40de5d79f80e4fb197e409fb99ab0fd8
to
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8
2014-01-16 01:01:26,142 INFO org.apache.hadoop.hbase.regionserver.Store:
Completed compaction of 1 file(s) in a of
storagetable,01:,1369377609136.7d8941661904fb99a41f79a1fce47767. into
40de5d79f80e4fb197e409fb99ab0fd8, size=534; total size for store is 399.0 M
2014-01-16 01:01:26,142 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactionRequest: completed
compaction:
regionName=storagetable,01:,1369377609136.7d8941661904fb99a41f79a1fce47767.,
storeName=a, fileCount=1, fileSize=534, priority=16, time=18280340606333745;
duration=0sec
{code}
(3) Select HFile for compaction
{code}
2014-01-16 03:48:05,120 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection: Deleting
the expired store file by compaction:
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8
whose maxTimeStamp is -1 while the max expired timestamp is 1389642485120
{code}
(4) Compact
{code}
2014-01-16 03:50:17,731 DEBUG org.apache.hadoop.hbase.regionserver.Compactor:
Compacting
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8,
keycount=0, bloomtype=NONE, size=534, encoding=NONE
2014-01-16 03:50:17,732 DEBUG org.apache.hadoop.hbase.util.FSUtils: Creating
file=hdfs://dump002002.cm6:9000/hbase-0.90
{code}
...
this loop for ever.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10371) Compact create empty hfile, then select this file for compaction and create empty hfile and over again.
[
https://issues.apache.org/jira/browse/HBASE-10371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10371:
---
Attachment: 10371-trunk-3.patch
Patch v3 corrects spelling mistake: entrys
Compact create empty hfile, then select this file for compaction and create
empty hfile and over again.
---
Key: HBASE-10371
URL: https://issues.apache.org/jira/browse/HBASE-10371
Project: HBase
Issue Type: Bug
Reporter: binlijin
Attachments: 10371-trunk-3.patch, HBASE-10371-94.patch,
HBASE-10371-trunk-2.patch, HBASE-10371-trunk.patch
(1) Select HFile for compaction
{code}
2014-01-16 01:01:25,111 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection: Deleting
the expired store file by compaction:
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/f3e38d10d579420494079e17a2557f0b
whose maxTimeStamp is -1 while the max expired timestamp is 1389632485111
{code}
(2) Compact
{code}
2014-01-16 01:01:26,042 DEBUG org.apache.hadoop.hbase.regionserver.Compactor:
Compacting
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/f3e38d10d579420494079e17a2557f0b,
keycount=0, bloomtype=NONE, size=534, encoding=NONE
2014-01-16 01:01:26,045 DEBUG org.apache.hadoop.hbase.util.FSUtils: Creating
file=hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/.tmp/40de5d79f80e4fb197e409fb99ab0fd8
with permission=rwxrwxrwx
2014-01-16 01:01:26,076 INFO org.apache.hadoop.hbase.regionserver.Store:
Renaming compacted file at
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/.tmp/40de5d79f80e4fb197e409fb99ab0fd8
to
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8
2014-01-16 01:01:26,142 INFO org.apache.hadoop.hbase.regionserver.Store:
Completed compaction of 1 file(s) in a of
storagetable,01:,1369377609136.7d8941661904fb99a41f79a1fce47767. into
40de5d79f80e4fb197e409fb99ab0fd8, size=534; total size for store is 399.0 M
2014-01-16 01:01:26,142 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactionRequest: completed
compaction:
regionName=storagetable,01:,1369377609136.7d8941661904fb99a41f79a1fce47767.,
storeName=a, fileCount=1, fileSize=534, priority=16, time=18280340606333745;
duration=0sec
{code}
(3) Select HFile for compaction
{code}
2014-01-16 03:48:05,120 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection: Deleting
the expired store file by compaction:
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8
whose maxTimeStamp is -1 while the max expired timestamp is 1389642485120
{code}
(4) Compact
{code}
2014-01-16 03:50:17,731 DEBUG org.apache.hadoop.hbase.regionserver.Compactor:
Compacting
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8,
keycount=0, bloomtype=NONE, size=534, encoding=NONE
2014-01-16 03:50:17,732 DEBUG org.apache.hadoop.hbase.util.FSUtils: Creating
file=hdfs://dump002002.cm6:9000/hbase-0.90
{code}
...
this loop for ever.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10349) Table became unusable when master balanced its region after table was dropped
[
https://issues.apache.org/jira/browse/HBASE-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875247#comment-13875247
]
Ted Yu commented on HBASE-10349:
+1 on patch v2.
New tests are good.
Table became unusable when master balanced its region after table was dropped
-
Key: HBASE-10349
URL: https://issues.apache.org/jira/browse/HBASE-10349
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.0
Reporter: Ted Yu
Assignee: Jimmy Xiang
Fix For: 0.98.0, 0.99.0
Attachments:
10349-hadoop-hdfs-namenode-hor11n14.gq1.ygridcore.net.zip, 10349-output.log,
10349-v1.txt, 10349-v2.txt, HBASE-10349-meta-test-and-debug.patch,
hbase-10349.patch, hbase-10349_v2.patch,
hbase-hbase-master-hor15n05.gq1.ygridcore.net.log.tar.gz
0.98 was used.
This was sequence of events:
create 'tablethree_mod'
snapshot 'tablethree_mod', 'snapshot_tablethree_mod'
disable 'tablethree_mod'
2014-01-15 09:34:51,749 restore_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:35:07,210 enable 'tablethree_mod'
2014-01-15 09:35:46,134 delete_snapshot 'snapshot_tablethree_mod'
2014-01-15 09:41:42,210 disable 'tablethree_mod'
2014-01-15 09:41:43,610 drop 'tablethree_mod'
create 'tablethree_mod'
For the last table creation request:
{code}
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'create 'tablethree_mod',
{NAME = 'f1', VERSIONS = 3}
,
{NAME = 'f2', VERSIONS = 3}
,
{NAME = 'f3', VERSIONS = 3}
'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'exists 'tablethree_mod''
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'0', 'f1:q1', 'value-0', 10'
2014-01-15 10:03:52,999|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'1', 'f1:q1', 'value-1', 20'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'2', 'f2:q2', 'value-2', 30'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'3', 'f3:q3', 'value-3', 40'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO| 'put 'tablethree_mod',
'4', 'f3:q3', 'value-4', 50'
2014-01-15 10:03:53,000|beaver.component.hbase|INFO|Done writing commands to
file. Will execute them now.
2014-01-15 10:03:53,000|beaver.machine|INFO|RUNNING: /usr/lib/hbase/bin/hbase
shell /grid/0/tmp/hwqe/artifacts/tmp-471142
2014-01-15 10:03:55,878|beaver.machine|INFO|2014-01-15 10:03:55,878 INFO
[main] Configuration.deprecation: hadoop.native.lib is deprecated. Instead,
use io.native.lib.available
2014-01-15 10:03:57,283|beaver.machine|INFO|2014-01-15 10:03:57,283 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,669|beaver.machine|INFO|2014-01-15 10:03:57,669 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,720|beaver.machine|INFO|2014-01-15 10:03:57,720 WARN
[main] conf.Configuration: hbase-site.xml:an attempt to override final
parameter: dfs.support.append; Ignoring.
2014-01-15 10:03:57,997|beaver.machine|INFO|
2014-01-15 10:03:57,997|beaver.machine|INFO|ERROR: Table already exists:
tablethree_mod!
2014-01-15 10:03:57,997|beaver.machine|INFO|
{code}
This was an intermittent issue after using Snapshots, a table is not properly
dropped / and not able to properly re-create with the same name. And a
HRegion is empty or null Error occurs. (When you try to drop the table it
says it does not exist, and when you try to create the table it says that it
does already exist).
{code}
2014-01-15 10:04:02,462|beaver.machine|INFO|ERROR: HRegionInfo was null or
empty in hbase:meta, row=keyvalues=
{tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:seqnumDuringOpen/1389778905355/Put/vlen=8/mvcc=0,
tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:server/1389778905355/Put/vlen=32/mvcc=0,
tablethree_mod,,1389778226606.afc82d1ceabbaca36a504b83b65fc0c9./info:serverstartcode/1389778905355/Put/vlen=8/mvcc=0}
{code}
Thanks to Huned who discovered this issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10371) Compaction creates empty hfile, then selects this file for compaction and creates empty hfile and over again
[
https://issues.apache.org/jira/browse/HBASE-10371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10371:
---
Summary: Compaction creates empty hfile, then selects this file for
compaction and creates empty hfile and over again (was: Compact create empty
hfile, then select this file for compaction and create empty hfile and over
again.)
Compaction creates empty hfile, then selects this file for compaction and
creates empty hfile and over again
Key: HBASE-10371
URL: https://issues.apache.org/jira/browse/HBASE-10371
Project: HBase
Issue Type: Bug
Reporter: binlijin
Attachments: 10371-trunk-3.patch, HBASE-10371-94.patch,
HBASE-10371-trunk-2.patch, HBASE-10371-trunk.patch
(1) Select HFile for compaction
{code}
2014-01-16 01:01:25,111 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection: Deleting
the expired store file by compaction:
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/f3e38d10d579420494079e17a2557f0b
whose maxTimeStamp is -1 while the max expired timestamp is 1389632485111
{code}
(2) Compact
{code}
2014-01-16 01:01:26,042 DEBUG org.apache.hadoop.hbase.regionserver.Compactor:
Compacting
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/f3e38d10d579420494079e17a2557f0b,
keycount=0, bloomtype=NONE, size=534, encoding=NONE
2014-01-16 01:01:26,045 DEBUG org.apache.hadoop.hbase.util.FSUtils: Creating
file=hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/.tmp/40de5d79f80e4fb197e409fb99ab0fd8
with permission=rwxrwxrwx
2014-01-16 01:01:26,076 INFO org.apache.hadoop.hbase.regionserver.Store:
Renaming compacted file at
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/.tmp/40de5d79f80e4fb197e409fb99ab0fd8
to
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8
2014-01-16 01:01:26,142 INFO org.apache.hadoop.hbase.regionserver.Store:
Completed compaction of 1 file(s) in a of
storagetable,01:,1369377609136.7d8941661904fb99a41f79a1fce47767. into
40de5d79f80e4fb197e409fb99ab0fd8, size=534; total size for store is 399.0 M
2014-01-16 01:01:26,142 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactionRequest: completed
compaction:
regionName=storagetable,01:,1369377609136.7d8941661904fb99a41f79a1fce47767.,
storeName=a, fileCount=1, fileSize=534, priority=16, time=18280340606333745;
duration=0sec
{code}
(3) Select HFile for compaction
{code}
2014-01-16 03:48:05,120 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection: Deleting
the expired store file by compaction:
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8
whose maxTimeStamp is -1 while the max expired timestamp is 1389642485120
{code}
(4) Compact
{code}
2014-01-16 03:50:17,731 DEBUG org.apache.hadoop.hbase.regionserver.Compactor:
Compacting
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8,
keycount=0, bloomtype=NONE, size=534, encoding=NONE
2014-01-16 03:50:17,732 DEBUG org.apache.hadoop.hbase.util.FSUtils: Creating
file=hdfs://dump002002.cm6:9000/hbase-0.90
{code}
...
this loop for ever.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10371) Compaction creates empty hfile, then selects this file for compaction and creates empty hfile and over again
[
https://issues.apache.org/jira/browse/HBASE-10371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875252#comment-13875252
]
Ted Yu commented on HBASE-10371:
Ran all compaction related tests which passed.
Integrated to 0.98 and trunk.
Thanks for the patch, Lijin.
Compaction creates empty hfile, then selects this file for compaction and
creates empty hfile and over again
Key: HBASE-10371
URL: https://issues.apache.org/jira/browse/HBASE-10371
Project: HBase
Issue Type: Bug
Reporter: binlijin
Attachments: 10371-trunk-3.patch, HBASE-10371-94.patch,
HBASE-10371-trunk-2.patch, HBASE-10371-trunk.patch
(1) Select HFile for compaction
{code}
2014-01-16 01:01:25,111 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection: Deleting
the expired store file by compaction:
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/f3e38d10d579420494079e17a2557f0b
whose maxTimeStamp is -1 while the max expired timestamp is 1389632485111
{code}
(2) Compact
{code}
2014-01-16 01:01:26,042 DEBUG org.apache.hadoop.hbase.regionserver.Compactor:
Compacting
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/f3e38d10d579420494079e17a2557f0b,
keycount=0, bloomtype=NONE, size=534, encoding=NONE
2014-01-16 01:01:26,045 DEBUG org.apache.hadoop.hbase.util.FSUtils: Creating
file=hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/.tmp/40de5d79f80e4fb197e409fb99ab0fd8
with permission=rwxrwxrwx
2014-01-16 01:01:26,076 INFO org.apache.hadoop.hbase.regionserver.Store:
Renaming compacted file at
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/.tmp/40de5d79f80e4fb197e409fb99ab0fd8
to
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8
2014-01-16 01:01:26,142 INFO org.apache.hadoop.hbase.regionserver.Store:
Completed compaction of 1 file(s) in a of
storagetable,01:,1369377609136.7d8941661904fb99a41f79a1fce47767. into
40de5d79f80e4fb197e409fb99ab0fd8, size=534; total size for store is 399.0 M
2014-01-16 01:01:26,142 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactionRequest: completed
compaction:
regionName=storagetable,01:,1369377609136.7d8941661904fb99a41f79a1fce47767.,
storeName=a, fileCount=1, fileSize=534, priority=16, time=18280340606333745;
duration=0sec
{code}
(3) Select HFile for compaction
{code}
2014-01-16 03:48:05,120 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection: Deleting
the expired store file by compaction:
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8
whose maxTimeStamp is -1 while the max expired timestamp is 1389642485120
{code}
(4) Compact
{code}
2014-01-16 03:50:17,731 DEBUG org.apache.hadoop.hbase.regionserver.Compactor:
Compacting
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8,
keycount=0, bloomtype=NONE, size=534, encoding=NONE
2014-01-16 03:50:17,732 DEBUG org.apache.hadoop.hbase.util.FSUtils: Creating
file=hdfs://dump002002.cm6:9000/hbase-0.90
{code}
...
this loop for ever.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10371) Compaction creates empty hfile, then selects this file for compaction and creates empty hfile and over again
[
https://issues.apache.org/jira/browse/HBASE-10371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10371:
---
Assignee: binlijin
Hadoop Flags: Reviewed
Compaction creates empty hfile, then selects this file for compaction and
creates empty hfile and over again
Key: HBASE-10371
URL: https://issues.apache.org/jira/browse/HBASE-10371
Project: HBase
Issue Type: Bug
Reporter: binlijin
Assignee: binlijin
Attachments: 10371-trunk-3.patch, HBASE-10371-94.patch,
HBASE-10371-trunk-2.patch, HBASE-10371-trunk.patch
(1) Select HFile for compaction
{code}
2014-01-16 01:01:25,111 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection: Deleting
the expired store file by compaction:
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/f3e38d10d579420494079e17a2557f0b
whose maxTimeStamp is -1 while the max expired timestamp is 1389632485111
{code}
(2) Compact
{code}
2014-01-16 01:01:26,042 DEBUG org.apache.hadoop.hbase.regionserver.Compactor:
Compacting
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/f3e38d10d579420494079e17a2557f0b,
keycount=0, bloomtype=NONE, size=534, encoding=NONE
2014-01-16 01:01:26,045 DEBUG org.apache.hadoop.hbase.util.FSUtils: Creating
file=hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/.tmp/40de5d79f80e4fb197e409fb99ab0fd8
with permission=rwxrwxrwx
2014-01-16 01:01:26,076 INFO org.apache.hadoop.hbase.regionserver.Store:
Renaming compacted file at
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/.tmp/40de5d79f80e4fb197e409fb99ab0fd8
to
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8
2014-01-16 01:01:26,142 INFO org.apache.hadoop.hbase.regionserver.Store:
Completed compaction of 1 file(s) in a of
storagetable,01:,1369377609136.7d8941661904fb99a41f79a1fce47767. into
40de5d79f80e4fb197e409fb99ab0fd8, size=534; total size for store is 399.0 M
2014-01-16 01:01:26,142 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactionRequest: completed
compaction:
regionName=storagetable,01:,1369377609136.7d8941661904fb99a41f79a1fce47767.,
storeName=a, fileCount=1, fileSize=534, priority=16, time=18280340606333745;
duration=0sec
{code}
(3) Select HFile for compaction
{code}
2014-01-16 03:48:05,120 INFO
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection: Deleting
the expired store file by compaction:
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8
whose maxTimeStamp is -1 while the max expired timestamp is 1389642485120
{code}
(4) Compact
{code}
2014-01-16 03:50:17,731 DEBUG org.apache.hadoop.hbase.regionserver.Compactor:
Compacting
hdfs://dump002002.cm6:9000/hbase-0.90/storagetable/7d8941661904fb99a41f79a1fce47767/a/40de5d79f80e4fb197e409fb99ab0fd8,
keycount=0, bloomtype=NONE, size=534, encoding=NONE
2014-01-16 03:50:17,732 DEBUG org.apache.hadoop.hbase.util.FSUtils: Creating
file=hdfs://dump002002.cm6:9000/hbase-0.90
{code}
...
this loop for ever.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10374) add jemalloc into the choice of memstore allocation
[ https://issues.apache.org/jira/browse/HBASE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875262#comment-13875262 ] Nick Dimiduk commented on HBASE-10374: -- Yeah, I tried this once and it didn't go very well. I am keen to pursue Stack's suggestion though. I haven't come to a conclusive decision for why we'd pursue Netty's ByteBuf vs nio add jemalloc into the choice of memstore allocation Key: HBASE-10374 URL: https://issues.apache.org/jira/browse/HBASE-10374 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.96.1.1 Reporter: Bing Jiang Priority: Minor https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead introduced that Netty used jemalloc to gain benefits from GC. It can be a good choice for memstore block allocation. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10374) add jemalloc into the choice of memstore allocation
[ https://issues.apache.org/jira/browse/HBASE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875265#comment-13875265 ] Nick Dimiduk commented on HBASE-10374: -- Premature submit. As I was a saying. I don't have conclusive reasons to pursue Netty ByteBufs vs nio ByteBuffers. The compositional structure Netty provides is really nice, if we can use it, but I think it could be implemented on top of stock ByteBuffers as well. add jemalloc into the choice of memstore allocation Key: HBASE-10374 URL: https://issues.apache.org/jira/browse/HBASE-10374 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.96.1.1 Reporter: Bing Jiang Priority: Minor https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead introduced that Netty used jemalloc to gain benefits from GC. It can be a good choice for memstore block allocation. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10346) Add Documentation for stateless scanner
[
https://issues.apache.org/jira/browse/HBASE-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875270#comment-13875270
]
Hadoop QA commented on HBASE-10346:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12623717/HBASE-10346.1.patch
against trunk revision .
ATTACHMENT ID: 12623717
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+Row key=dGVzdHJvdzE=gt;lt;Cell column=YTox
timestamp=1389900769772gt;dGVzdHZhbHVlLWExlt;br
+dGVzdHZhbHVlLWEylt;/Cellgt;lt;Cell
column=Yjoxtimestamp=1389900818233gt;dGVzdHZhbHVlLWIylt;br
+/Cellgt;lt;/Rowgt;lt;Row key=dGVzdHJvdzM=gt;lt;Cell column=YTox
timestamp=1389900847336br
+Row key=dGVzdHJvdzE=gt;lt;Cell column=YTox
timestamp=1389900769772gt;dGVzdHZhbHVlLWExlt;br
+curl -H Content-Type: text/xml
https://localhost:8080/ExampleScanner/*?startrow=testrow1amp;limit=2
+Row key=dGVzdHJvdzE=gt;lt;Cell column=YTox
timestamp=1389900769772gt;dGVzdHZhbHVlLWExlt;br
+curl -H Content-Type: text/xml
https://localhost:8080/ExampleScanner/*?starttime=1389900769772amp;endtime=138990080
+Row key=dGVzdHJvdzE=gt;lt;Cell column=YTox
timestamp=1389900769772gt;dGVzdHZhbHVlLWExlt;br
+Row key=dGVzdHJvdzE=gt;lt;Cell column=YTox
timestamp=1389900769772gt;dGVzdHZhbHVlLWExlt;br
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8464//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8464//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8464//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8464//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8464//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8464//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8464//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8464//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8464//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8464//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8464//console
This message is automatically generated.
Add Documentation for stateless scanner
---
Key: HBASE-10346
URL: https://issues.apache.org/jira/browse/HBASE-10346
Project: HBase
Issue Type: Improvement
Components: REST
Reporter: Vandana Ayyalasomayajula
Assignee: Vandana Ayyalasomayajula
Priority: Minor
Fix For: 0.98.0, 0.99.0
Attachments: HBASE-10346.0.patch, HBASE-10346.1.patch
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10346) Add Documentation for stateless scanner
[ https://issues.apache.org/jira/browse/HBASE-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875280#comment-13875280 ] Nick Dimiduk commented on HBASE-10346: -- The additional docs look great! Mind cleaning up the line length issues for me, I'll get it committed today. Add Documentation for stateless scanner --- Key: HBASE-10346 URL: https://issues.apache.org/jira/browse/HBASE-10346 Project: HBase Issue Type: Improvement Components: REST Reporter: Vandana Ayyalasomayajula Assignee: Vandana Ayyalasomayajula Priority: Minor Fix For: 0.98.0, 0.99.0 Attachments: HBASE-10346.0.patch, HBASE-10346.1.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10346) Add Documentation for stateless scanner
[ https://issues.apache.org/jira/browse/HBASE-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875281#comment-13875281 ] Nick Dimiduk commented on HBASE-10346: -- Oh, it's all in the preformatted output. Nevermind. +1 Add Documentation for stateless scanner --- Key: HBASE-10346 URL: https://issues.apache.org/jira/browse/HBASE-10346 Project: HBase Issue Type: Improvement Components: REST Reporter: Vandana Ayyalasomayajula Assignee: Vandana Ayyalasomayajula Priority: Minor Fix For: 0.98.0, 0.99.0 Attachments: HBASE-10346.0.patch, HBASE-10346.1.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10366) 0.94 filterRow() may be skipped in 0.96(or onwards) code
[ https://issues.apache.org/jira/browse/HBASE-10366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeffrey Zhong updated HBASE-10366: -- Attachment: hbase-10366-v1.patch Thanks All for the reviews! v1 patch adds a unit test. [~te...@apache.org] The Javadoc for current hasFilterRow() is all right because new filter implementation should follow that way in the future. I modified some comments in my previous patch to specifically call out that 0.94 hasFilterRow() has different semantics. 0.94 filterRow() may be skipped in 0.96(or onwards) code Key: HBASE-10366 URL: https://issues.apache.org/jira/browse/HBASE-10366 Project: HBase Issue Type: Bug Components: Filters Reporter: Jeffrey Zhong Assignee: Jeffrey Zhong Priority: Critical Fix For: 0.98.0, 0.96.2 Attachments: hbase-10366-v1.patch, hbase-10366.patch HBASE-6429 combines both filterRow filterRow(ListKeyValue kvs) functions in Filter. While 0.94 code or older, it may not implement hasFilterRow as HBase-6429 expected because 0.94(old) hasFilterRow only returns true when filterRow(ListKeyValue kvs) is overridden not the filterRow(). Therefore, the filterRow() will be skipped. Since we don't ask 0.94 users to update their existing filter code, the issue will cause scan returns unexpected keyvalues and break the backward compatibility. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10346) Add Documentation for stateless scanner
[ https://issues.apache.org/jira/browse/HBASE-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated HBASE-10346: - Attachment: HBASE-10346.addendum.patch I jumped the gun, committed patch 0, not patch 1, to both 0.98 and trunk. This is the interdiff between the two. I'm verifying it applies cleanly and I'll commit it as an addendum. Add Documentation for stateless scanner --- Key: HBASE-10346 URL: https://issues.apache.org/jira/browse/HBASE-10346 Project: HBase Issue Type: Improvement Components: REST Reporter: Vandana Ayyalasomayajula Assignee: Vandana Ayyalasomayajula Priority: Minor Fix For: 0.98.0, 0.99.0 Attachments: HBASE-10346.0.patch, HBASE-10346.1.patch, HBASE-10346.addendum.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875312#comment-13875312
]
Hudson commented on HBASE-10370:
FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #82 (See
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/82/])
HBASE-10370 Compaction in out-of-date Store causes region split failed (Tedyu:
rev 1559215)
*
/hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
*
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransactionOnCluster.java
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10374) add jemalloc into the choice of memstore allocation
[ https://issues.apache.org/jira/browse/HBASE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875319#comment-13875319 ] Andrew Purtell commented on HBASE-10374: This is also directly related to HBASE-10191 add jemalloc into the choice of memstore allocation Key: HBASE-10374 URL: https://issues.apache.org/jira/browse/HBASE-10374 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.96.1.1 Reporter: Bing Jiang Priority: Minor https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead introduced that Netty used jemalloc to gain benefits from GC. It can be a good choice for memstore block allocation. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875318#comment-13875318
]
Hudson commented on HBASE-10370:
FAILURE: Integrated in hbase-0.96 #261 (See
[https://builds.apache.org/job/hbase-0.96/261/])
HBASE-10370 Compaction in out-of-date Store causes region split failed (stack:
rev 1559226)
*
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10346) Add Documentation for stateless scanner
[
https://issues.apache.org/jira/browse/HBASE-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875327#comment-13875327
]
Hadoop QA commented on HBASE-10346:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12623735/HBASE-10346.addendum.patch
against trunk revision .
ATTACHMENT ID: 12623735
{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/8466//console
This message is automatically generated.
Add Documentation for stateless scanner
---
Key: HBASE-10346
URL: https://issues.apache.org/jira/browse/HBASE-10346
Project: HBase
Issue Type: Improvement
Components: REST
Reporter: Vandana Ayyalasomayajula
Assignee: Vandana Ayyalasomayajula
Priority: Minor
Fix For: 0.98.0, 0.99.0
Attachments: HBASE-10346.0.patch, HBASE-10346.1.patch,
HBASE-10346.addendum.patch
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875335#comment-13875335
]
Hudson commented on HBASE-10370:
FAILURE: Integrated in HBase-0.98 #91 (See
[https://builds.apache.org/job/HBase-0.98/91/])
HBASE-10370 Compaction in out-of-date Store causes region split failed (Tedyu:
rev 1559215)
*
/hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
*
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransactionOnCluster.java
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10346) Add Documentation for stateless scanner
[ https://issues.apache.org/jira/browse/HBASE-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated HBASE-10346: - Resolution: Fixed Status: Resolved (was: Patch Available) Committed to 0.98 and trunk. Add Documentation for stateless scanner --- Key: HBASE-10346 URL: https://issues.apache.org/jira/browse/HBASE-10346 Project: HBase Issue Type: Improvement Components: REST Reporter: Vandana Ayyalasomayajula Assignee: Vandana Ayyalasomayajula Priority: Minor Fix For: 0.98.0, 0.99.0 Attachments: HBASE-10346.0.patch, HBASE-10346.1.patch, HBASE-10346.addendum.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875351#comment-13875351
]
Ted Yu commented on HBASE-10370:
From
https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/82/testReport/org.apache.hadoop.hbase.regionserver/TestSplitTransactionOnCluster/testSplitFailedCompactionAndSplit/
:
{code}
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:621)
at org.junit.Assert.assertNotNull(Assert.java:631)
at
org.apache.hadoop.hbase.regionserver.TestSplitTransactionOnCluster.testSplitFailedCompactionAndSplit(TestSplitTransactionOnCluster.java:335)
{code}
The following assertion failed:
{code}
CompactionContext cc = store.requestCompaction();
assertNotNull(cc);
{code}
Since the above is in the new test added, I will revert from 0.98 and trunk.
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875348#comment-13875348
]
Hudson commented on HBASE-10370:
SUCCESS: Integrated in HBase-TRUNK #4831 (See
[https://builds.apache.org/job/HBase-TRUNK/4831/])
HBASE-10370 Compaction in out-of-date Store causes region split failed (Tedyu:
rev 1559216)
*
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransactionOnCluster.java
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875353#comment-13875353
]
Andrew Purtell commented on HBASE-10370:
bq. I will revert from 0.98 and trunk
Thanks Ted.
+1 to recommit without the new test, or with a fixed test.
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875355#comment-13875355
]
Andrew Purtell commented on HBASE-10370:
This could also be handled with an addendum that drops the new test, since this
was committed to 0.96 without the new test.
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875356#comment-13875356
]
Ted Yu commented on HBASE-10370:
bq. or with a fixed test
I prefer the above.
Thanks Andy.
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875366#comment-13875366
]
Andrew Purtell commented on HBASE-10370:
Well this was committed elsewhere without the new test, so I'd prefer that if
you don't mind.
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875368#comment-13875368
]
Ted Yu commented on HBASE-10370:
Okay.
I will integrate one more time before 0.98.0 RC0 comes out.
Let's give Shaohui some time to make the test robust.
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875370#comment-13875370
]
Andrew Purtell commented on HBASE-10370:
Can we commit this to 0.98 as was committed to 0.96 and open a followup JIRA
for a test for both 0.98 and 0.96 (at Stack's option)?
bq. I will integrate one more time before 0.98.0 RC0 comes out.
Ok, the only blocker remaining is HBASE-10322. I'm going to tag the RC as soon
as that goes in.
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370v2.096.txt, HBASE-10370-v1.diff,
HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (HBASE-10376) Backport JvmPauseMonitor to 0.94 branch
Ted Yu created HBASE-10376: -- Summary: Backport JvmPauseMonitor to 0.94 branch Key: HBASE-10376 URL: https://issues.apache.org/jira/browse/HBASE-10376 Project: HBase Issue Type: Task Reporter: Ted Yu In the following thread: http://search-hadoop.com/m/NniICiuKee1 Nick mentioned using JvmPauseMonitor to help track down an anomaly. This JIRA is to backport JvmPauseMonitor (introduced in HBASE-9630) to 0.94 branch -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10370:
---
Attachment: 10370-v4.patch
Sounds good.
Patch v4 is the fix without test.
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370-v4.patch, 10370v2.096.txt,
HBASE-10370-v1.diff, HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10370) Compaction in out-of-date Store causes region split failed
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10370:
---
Status: Open (was: Patch Available)
Compaction in out-of-date Store causes region split failed
--
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370-v4.patch, 10370v2.096.txt,
HBASE-10370-v1.diff, HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10370) Compaction in out-of-date Store causes region split failure
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10370:
---
Summary: Compaction in out-of-date Store causes region split failure (was:
Compaction in out-of-date Store causes region split failed)
Compaction in out-of-date Store causes region split failure
---
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370-v4.patch, 10370v2.096.txt,
HBASE-10370-v1.diff, HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (HBASE-10377) Add test for HBASE-10370 Compaction in out-of-date Store causes region split failure
Ted Yu created HBASE-10377: -- Summary: Add test for HBASE-10370 Compaction in out-of-date Store causes region split failure Key: HBASE-10377 URL: https://issues.apache.org/jira/browse/HBASE-10377 Project: HBase Issue Type: Test Reporter: Ted Yu HBASE-10370 fixes the issue where region split fails following compacting out-of-date Store The new test failed in this build: https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/82/testReport/org.apache.hadoop.hbase.regionserver/TestSplitTransactionOnCluster/testSplitFailedCompactionAndSplit/ This issue is to make the new test, testSplitFailedCompactionAndSplit, robust. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10370) Compaction in out-of-date Store causes region split failure
[
https://issues.apache.org/jira/browse/HBASE-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875385#comment-13875385
]
Ted Yu commented on HBASE-10370:
Re-integrated the fix into 0.98 and trunk.
I created HBASE-10377 for restoring the test.
Once Jenkins builds come back green, will resolve this issue.
Compaction in out-of-date Store causes region split failure
---
Key: HBASE-10370
URL: https://issues.apache.org/jira/browse/HBASE-10370
Project: HBase
Issue Type: Bug
Components: Compaction
Affects Versions: 0.94.3, 0.98.0, 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Critical
Fix For: 0.98.0, 0.96.2, 0.99.0
Attachments: 10370-v3.patch, 10370-v4.patch, 10370v2.096.txt,
HBASE-10370-v1.diff, HBASE-10370-v2.diff
In out product cluster, we encounter a problem that two daughter regions can
not been opened for FileNotFoundException.
{quote}
2014-01-14,20:12:46,927 INFO
org.apache.hadoop.hbase.regionserver.SplitRequest: Running rollback/cleanup
of failed split of
user_profile,x,1389671863815.99e016485b0bc142d67ae07a884f6966.;
Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
java.io.IOException: Failed
lg-hadoop-st34.bj,21600,1389060755669-daughterOpener=ec8bbda0f132c481b451fa40e7152b98
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:375)
at
org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:467)
at
org.apache.hadoop.hbase.regionserver.SplitRequest.run(SplitRequest.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist:
/hbase/lgprc-xiaomi/user_profile/99e016485b0bc142d67ae07a884f6966/A/5e05d706e4a84f34acc2cf00f089a4cf
{quote}
The reason is that a compaction in an out-of-date Store deletes the hfiles,
which are referenced by the daughter regions after split. This will cause
the daughter regions can not be opened forever.
The timeline is that
Assumption: there are two hfiles: a, b in Store A in Region R
t0: A compaction request of Store A(a+b) in Region R is sent.
t1: First Split for Region R. But this split is timeout and rollbacked. In
the rollback, region reinitializes all store objects , see SplitTransaction
#824. Now the store is Region R is A'(a+b).
t2: Run the compaction sent in t0 . (hfile: a + b - c): A(a+b) - A(c).
Hfile a and b are archived.
t3: Another Split for Region R. R splits into two region R.0, R.1, which
create hfile references for hfile a, b from Store A'(a + b)
t4: For hfile a, b have been deleted, the opening for region R.0 and R.1 will
failed for FileNotFoundException.
I have add a test to identity this problem.
After search the jira, maybe HBASE-8502 is the same problem. [~goldin]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
