[jira] [Commented] (HBASE-4225) NoSuchColumnFamilyException in multi doesn't say which family is bad
[
https://issues.apache.org/jira/browse/HBASE-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090018#comment-13090018
]
ramkrishna.s.vasudevan commented on HBASE-4225:
---
Thanks Ted, JD and Stack.
@JD
I will do follow what you said. Thanks once again.
NoSuchColumnFamilyException in multi doesn't say which family is bad
Key: HBASE-4225
URL: https://issues.apache.org/jira/browse/HBASE-4225
Project: HBase
Issue Type: Improvement
Affects Versions: 0.90.4
Reporter: Jean-Daniel Cryans
Assignee: ramkrishna.s.vasudevan
Priority: Critical
Fix For: 0.90.5
Attachments: 4225.trunk, HBASE-4225_0.90.patch,
HBASE-4225_0.90_1.patch, HBASE-4225_0.90_2.patch, HBASE-4225_0.90_3.patch
It's kind of a dumb one, in HRegion.doMiniBatchPut we do:
{code}
LOG.warn(No such column family in batch put, nscf);
batchOp.retCodes[lastIndexExclusive] = OperationStatusCode.BAD_FAMILY;
{code}
So we lose the family here, all we know is there's a bad one, that's what's
in HRS.multi:
{code}
} else if (code == OperationStatusCode.BAD_FAMILY) {
result = new NoSuchColumnFamilyException();
{code}
We can't just throw the exception like that, we need to say which one is bad
even if it requires testing all passed MultiActions.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4242) Add documentation for HBASE-4071
[ https://issues.apache.org/jira/browse/HBASE-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-4242: - Attachment: 4242.txt Here's a stab at it. If somebody could point to how to build the HBase locally that would be great. Add documentation for HBASE-4071 Key: HBASE-4242 URL: https://issues.apache.org/jira/browse/HBASE-4242 Project: HBase Issue Type: Sub-task Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Priority: Minor Attachments: 4242.txt Add documentation for min versions to the HBase book. I'll add patch soon. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4015) Refactor the TimeoutMonitor to make it less racy
[ https://issues.apache.org/jira/browse/HBASE-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090025#comment-13090025 ] Ted Yu commented on HBASE-4015: --- In TRUNK, HRegionInfo.isMetaRegion() only checks for .META. Refactor the TimeoutMonitor to make it less racy Key: HBASE-4015 URL: https://issues.apache.org/jira/browse/HBASE-4015 Project: HBase Issue Type: Sub-task Affects Versions: 0.90.3 Reporter: Jean-Daniel Cryans Assignee: ramkrishna.s.vasudevan Priority: Blocker Fix For: 0.92.0 Attachments: HBASE-4015_1_trunk.patch, HBASE-4015_2_trunk.patch, Timeoutmonitor with state diagrams.pdf The current implementation of the TimeoutMonitor acts like a race condition generator, mostly making things worse rather than better. It does it's own thing for a while without caring for what's happening in the rest of the master. The first thing that needs to happen is that the regions should not be processed in one big batch, because that sometimes can take minutes to process (meanwhile a region that timed out opening might have opened, then what happens is it will be reassigned by the TimeoutMonitor generating the never ending PENDING_OPEN situation). Those operations should also be done more atomically, although I'm not sure how to do it in a scalable way in this case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-4242) Add documentation for HBASE-4071
[ https://issues.apache.org/jira/browse/HBASE-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4242. -- Resolution: Fixed Fix Version/s: 0.92.0 Hadoop Flags: [Reviewed] Committed to TRUNK. Thanks for patch Lars. To build docbook, you can do 'mvn pre-site'. This is mvn goal that gens the docbook output. To build full site, do 'mvn -DskipTests site'. Usually I'll just do: $ xmllint src/docbkx/book.xml ...after patch submission to ensure all is well-formed. Thats usually enough. Good stuff Lars. Add documentation for HBASE-4071 Key: HBASE-4242 URL: https://issues.apache.org/jira/browse/HBASE-4242 Project: HBase Issue Type: Sub-task Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Priority: Minor Fix For: 0.92.0 Attachments: 4242.txt Add documentation for min versions to the HBase book. I'll add patch soon. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4015) Refactor the TimeoutMonitor to make it less racy
[
https://issues.apache.org/jira/browse/HBASE-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090031#comment-13090031
]
ramkrishna.s.vasudevan commented on HBASE-4015:
---
Thanks for your comments Ted and Stack.
{bq}Why the special handling of meta regions here:
This is for the issue HBASE-4203. I should have commented in this JIRA also
about this.
All the formatting issues i will address it.
I will explain in detail the major race conditions and which parts of PATCH-2
handles corresponding scenarios.
Refactor the TimeoutMonitor to make it less racy
Key: HBASE-4015
URL: https://issues.apache.org/jira/browse/HBASE-4015
Project: HBase
Issue Type: Sub-task
Affects Versions: 0.90.3
Reporter: Jean-Daniel Cryans
Assignee: ramkrishna.s.vasudevan
Priority: Blocker
Fix For: 0.92.0
Attachments: HBASE-4015_1_trunk.patch, HBASE-4015_2_trunk.patch,
Timeoutmonitor with state diagrams.pdf
The current implementation of the TimeoutMonitor acts like a race condition
generator, mostly making things worse rather than better. It does it's own
thing for a while without caring for what's happening in the rest of the
master.
The first thing that needs to happen is that the regions should not be
processed in one big batch, because that sometimes can take minutes to
process (meanwhile a region that timed out opening might have opened, then
what happens is it will be reassigned by the TimeoutMonitor generating the
never ending PENDING_OPEN situation).
Those operations should also be done more atomically, although I'm not sure
how to do it in a scalable way in this case.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4015) Refactor the TimeoutMonitor to make it less racy
[
https://issues.apache.org/jira/browse/HBASE-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090032#comment-13090032
]
Ted Yu commented on HBASE-4015:
---
At line 1098 in AssignmentManager.java, calling assign(state, setOfflineInZK,
forceNewPlan, isReAllocate) would suffice:
{code}
if (!isReAllocate) {
assign(state, setOfflineInZK, forceNewPlan);
} else {
assign(state, setOfflineInZK, forceNewPlan, isReAllocate);
}
{code}
Refactor the TimeoutMonitor to make it less racy
Key: HBASE-4015
URL: https://issues.apache.org/jira/browse/HBASE-4015
Project: HBase
Issue Type: Sub-task
Affects Versions: 0.90.3
Reporter: Jean-Daniel Cryans
Assignee: ramkrishna.s.vasudevan
Priority: Blocker
Fix For: 0.92.0
Attachments: HBASE-4015_1_trunk.patch, HBASE-4015_2_trunk.patch,
Timeoutmonitor with state diagrams.pdf
The current implementation of the TimeoutMonitor acts like a race condition
generator, mostly making things worse rather than better. It does it's own
thing for a while without caring for what's happening in the rest of the
master.
The first thing that needs to happen is that the regions should not be
processed in one big batch, because that sometimes can take minutes to
process (meanwhile a region that timed out opening might have opened, then
what happens is it will be reassigned by the TimeoutMonitor generating the
never ending PENDING_OPEN situation).
Those operations should also be done more atomically, although I'm not sure
how to do it in a scalable way in this case.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4015) Refactor the TimeoutMonitor to make it less racy
[ https://issues.apache.org/jira/browse/HBASE-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090034#comment-13090034 ] Ted Yu commented on HBASE-4015: --- @Ramkrishna: Can you publish patch 2 on reviewboard for further comments ? Refactor the TimeoutMonitor to make it less racy Key: HBASE-4015 URL: https://issues.apache.org/jira/browse/HBASE-4015 Project: HBase Issue Type: Sub-task Affects Versions: 0.90.3 Reporter: Jean-Daniel Cryans Assignee: ramkrishna.s.vasudevan Priority: Blocker Fix For: 0.92.0 Attachments: HBASE-4015_1_trunk.patch, HBASE-4015_2_trunk.patch, Timeoutmonitor with state diagrams.pdf The current implementation of the TimeoutMonitor acts like a race condition generator, mostly making things worse rather than better. It does it's own thing for a while without caring for what's happening in the rest of the master. The first thing that needs to happen is that the regions should not be processed in one big batch, because that sometimes can take minutes to process (meanwhile a region that timed out opening might have opened, then what happens is it will be reassigned by the TimeoutMonitor generating the never ending PENDING_OPEN situation). Those operations should also be done more atomically, although I'm not sure how to do it in a scalable way in this case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4195) Possible inconsistency in a memstore read after a reseek, possible performance improvement
[
https://issues.apache.org/jira/browse/HBASE-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090040#comment-13090040
]
stack commented on HBASE-4195:
--
bq. Problem solved then
Ehh... not exactly (smile)
bq. For #1, note that the previous implementation will completly ignore the
modifications made during the flush: the flush creates a new KV List (kvset),
and this list is not seen by the MemScanner, as it uses the previous iterator.
I don't know if it's an issue or not.
This is what we want, right? A consistent view across the flush; definitely
not part of 'snapshot' only.
Your suggested fix sounds good (we'll keep iterators on whatever the sets were
when scan started in spite of a flush coming in midway through the scan?)
Possible inconsistency in a memstore read after a reseek, possible
performance improvement
--
Key: HBASE-4195
URL: https://issues.apache.org/jira/browse/HBASE-4195
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.90.4
Environment: all
Reporter: nkeywal
Priority: Critical
This follows the dicussion around HBASE-3855, and the random errors (20%
failure on trunk) on the unit test
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
I saw some points related to numIterReseek, used in the
MemStoreScanner#getNext (line 690):
{noformat}679 protected KeyValue getNext(Iterator it) {
680 KeyValue ret = null;
681 long readPoint = ReadWriteConsistencyControl.getThreadReadPoint();
682 //DebugPrint.println( MS@ + hashCode() + : threadpoint = +
readPoint);
683
684 while (ret == null it.hasNext()) {
685 KeyValue v = it.next();
686 if (v.getMemstoreTS() = readPoint) {
687 // keep it.
688 ret = v;
689 }
690 numIterReseek--;
691 if (numIterReseek == 0) {
692 break;
693}
694 }
695 return ret;
696 }{noformat}
This function is called by seek, reseek, and next. The numIterReseek is only
usefull for reseek.
There are some issues, I am not totally sure it's the root cause of the test
case error, but it could explain partly the randomness of the error, and one
point is for sure a bug.
1) In getNext, numIterReseek is decreased, then compared to zero. The seek
function sets numIterReseek to zero before calling getNext. It means that the
value will be actually negative, hence the test will always fail, and the
loop will continue. It is the expected behaviour, but it's quite smart.
2) In reseek, numIterReseek is not set between the loops on the two
iterators. If the numIterReseek is equals to zero after the loop on the first
one, the loop on the second one will never call seek, as numIterReseek will
be negative.
3) Still in reseek, the test to call seek is (kvsetNextRow == null
numIterReseek == 0). In other words, if kvsetNextRow is not null when
numIterReseek equals zero, numIterReseek will start to be negative at the
next iteration and seek will never be called.
4) You can have side effects if reseek ends with a numIterReseek 0: the
following calls to the next function will decrease numIterReseek to zero,
and getNext will break instead of continuing the loop. As a result, later
calls to next() may return null or not depending on how is configured the
default value for numIterReseek.
To check if the issue comes from point 4, you can set the numIterReseek to
zero before returning in reseek:
{noformat} numIterReseek = 0;
return (kvsetNextRow != null || snapshotNextRow != null);
}{noformat}
On my env, on trunk, it seems to work, but as it's random I am not really
sure. I also had to modify the test (I added a loop) to make it fails more
often, the original test was working quite well here.
It has to be confirmed that this totally fix (it could be partial or
unrelated)
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
before implementing a complete solution.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4188) Make in-memory table scanning faster, part2 (continuation of hbase-1938)
[ https://issues.apache.org/jira/browse/HBASE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090047#comment-13090047 ] stack commented on HBASE-4188: -- Hmm... so I still see fails. Out of 42 runs, three failed which is less than previous Make in-memory table scanning faster, part2 (continuation of hbase-1938) Key: HBASE-4188 URL: https://issues.apache.org/jira/browse/HBASE-4188 Project: HBase Issue Type: Improvement Components: performance Reporter: stack Assignee: nkeywal Priority: Critical Fix For: 0.92.0 Attachments: 4188-mssp.txt This issue is a continuation of hbase-1938 work (That issue is closed). This issue is about getting the last patch posted by nkeywal over in hbase-1938 applied (assigned nkeywal since he's done the work). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4138) If zookeeper.znode.parent is not specifed explicitly in Client code then HTable object loops continuously waiting for the root region by using /hbase as the base node.
[ https://issues.apache.org/jira/browse/HBASE-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090049#comment-13090049 ] ramkrishna.s.vasudevan commented on HBASE-4138: --- Even build #2119 failed and the same 3 testcases failed due to the same exception. If zookeeper.znode.parent is not specifed explicitly in Client code then HTable object loops continuously waiting for the root region by using /hbase as the base node. --- Key: HBASE-4138 URL: https://issues.apache.org/jira/browse/HBASE-4138 Project: HBase Issue Type: Bug Components: client Affects Versions: 0.90.3 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.92.0 Attachments: HBASE-4138_trunk_1.patch, HBASE-4138_trunk_2.patch, HBASE-4138_trunk_3.patch Change the zookeeper.znode.parent property (default is /hbase). Now do not specify this change in the client code. Use the HTable Object. The HTable is not able to find the root region and keeps continuously looping. Find the stack trace: Object.wait(long) line: not available [native method] RootRegionTracker(ZooKeeperNodeTracker).blockUntilAvailable(long) line: 122 RootRegionTracker.waitRootRegionLocation(long) line: 73 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 578 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[], byte[], byte[], boolean, Object) line: 687 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 589 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[], byte[], byte[], boolean, Object) line: 687 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 593 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HTable.init(Configuration, byte[]) line: 171 HTable.init(Configuration, String) line: 145 HBaseTest.test() line: 45 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4015) Refactor the TimeoutMonitor to make it less racy
[ https://issues.apache.org/jira/browse/HBASE-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090069#comment-13090069 ] ramkrishna.s.vasudevan commented on HBASE-4015: --- @Ted Fine.. i will do that. The patch has become outdated. I will update and send it to review board. Refactor the TimeoutMonitor to make it less racy Key: HBASE-4015 URL: https://issues.apache.org/jira/browse/HBASE-4015 Project: HBase Issue Type: Sub-task Affects Versions: 0.90.3 Reporter: Jean-Daniel Cryans Assignee: ramkrishna.s.vasudevan Priority: Blocker Fix For: 0.92.0 Attachments: HBASE-4015_1_trunk.patch, HBASE-4015_2_trunk.patch, Timeoutmonitor with state diagrams.pdf The current implementation of the TimeoutMonitor acts like a race condition generator, mostly making things worse rather than better. It does it's own thing for a while without caring for what's happening in the rest of the master. The first thing that needs to happen is that the regions should not be processed in one big batch, because that sometimes can take minutes to process (meanwhile a region that timed out opening might have opened, then what happens is it will be reassigned by the TimeoutMonitor generating the never ending PENDING_OPEN situation). Those operations should also be done more atomically, although I'm not sure how to do it in a scalable way in this case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4195) Possible inconsistency in a memstore read after a reseek, possible performance improvement
[
https://issues.apache.org/jira/browse/HBASE-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090073#comment-13090073
]
nkeywal commented on HBASE-4195:
The behavior we have with the previous (or with the one I propose)
implementation is:
* before the flush, the MemScanner iterator points on the KV Lists of the
MemStore. So the put on the MemStore.kvset will be seen by the scanner.
* The flush does:
snapshot = kvset;
kvset = new SkipList();
* So after the flush, the put will be made on the new Memstore.kvset,
hence not visible by the existing scanner. So the memScanner behaves
differently before after the flush.
But may be it's not an issue as these put could be skipped anyway by the
readpoint criteria ? I just don't know. This state does not last long, as
the Store will recreate the scanner when notified of the flush.
Possible inconsistency in a memstore read after a reseek, possible
performance improvement
--
Key: HBASE-4195
URL: https://issues.apache.org/jira/browse/HBASE-4195
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.90.4
Environment: all
Reporter: nkeywal
Priority: Critical
This follows the dicussion around HBASE-3855, and the random errors (20%
failure on trunk) on the unit test
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
I saw some points related to numIterReseek, used in the
MemStoreScanner#getNext (line 690):
{noformat}679 protected KeyValue getNext(Iterator it) {
680 KeyValue ret = null;
681 long readPoint = ReadWriteConsistencyControl.getThreadReadPoint();
682 //DebugPrint.println( MS@ + hashCode() + : threadpoint = +
readPoint);
683
684 while (ret == null it.hasNext()) {
685 KeyValue v = it.next();
686 if (v.getMemstoreTS() = readPoint) {
687 // keep it.
688 ret = v;
689 }
690 numIterReseek--;
691 if (numIterReseek == 0) {
692 break;
693}
694 }
695 return ret;
696 }{noformat}
This function is called by seek, reseek, and next. The numIterReseek is only
usefull for reseek.
There are some issues, I am not totally sure it's the root cause of the test
case error, but it could explain partly the randomness of the error, and one
point is for sure a bug.
1) In getNext, numIterReseek is decreased, then compared to zero. The seek
function sets numIterReseek to zero before calling getNext. It means that the
value will be actually negative, hence the test will always fail, and the
loop will continue. It is the expected behaviour, but it's quite smart.
2) In reseek, numIterReseek is not set between the loops on the two
iterators. If the numIterReseek is equals to zero after the loop on the first
one, the loop on the second one will never call seek, as numIterReseek will
be negative.
3) Still in reseek, the test to call seek is (kvsetNextRow == null
numIterReseek == 0). In other words, if kvsetNextRow is not null when
numIterReseek equals zero, numIterReseek will start to be negative at the
next iteration and seek will never be called.
4) You can have side effects if reseek ends with a numIterReseek 0: the
following calls to the next function will decrease numIterReseek to zero,
and getNext will break instead of continuing the loop. As a result, later
calls to next() may return null or not depending on how is configured the
default value for numIterReseek.
To check if the issue comes from point 4, you can set the numIterReseek to
zero before returning in reseek:
{noformat} numIterReseek = 0;
return (kvsetNextRow != null || snapshotNextRow != null);
}{noformat}
On my env, on trunk, it seems to work, but as it's random I am not really
sure. I also had to modify the test (I added a loop) to make it fails more
often, the original test was working quite well here.
It has to be confirmed that this totally fix (it could be partial or
unrelated)
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
before implementing a complete solution.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4124) ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'.
[ https://issues.apache.org/jira/browse/HBASE-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gaojinchao updated HBASE-4124: -- Attachment: HBASE-4124_Branch90V3.patch ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'. Key: HBASE-4124 URL: https://issues.apache.org/jira/browse/HBASE-4124 Project: HBase Issue Type: Bug Components: master Reporter: fulin wang Assignee: gaojinchao Fix For: 0.90.5 Attachments: HBASE-4124_Branch90V1_trial.patch, HBASE-4124_Branch90V2.patch, HBASE-4124_Branch90V3.patch, log.txt Original Estimate: 0.4h Remaining Estimate: 0.4h ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'. Issue: The RS failed besause of 'already online on this server' and return; The HM can not receive the message and report 'Regions in transition timed out'. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4124) ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'.
[ https://issues.apache.org/jira/browse/HBASE-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090141#comment-13090141 ] gaojinchao commented on HBASE-4124: --- @Ted Does it need a patch for Trunk? There is a big change, I need some time to study it. ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'. Key: HBASE-4124 URL: https://issues.apache.org/jira/browse/HBASE-4124 Project: HBase Issue Type: Bug Components: master Reporter: fulin wang Assignee: gaojinchao Fix For: 0.90.5 Attachments: HBASE-4124_Branch90V1_trial.patch, HBASE-4124_Branch90V2.patch, HBASE-4124_Branch90V3.patch, log.txt Original Estimate: 0.4h Remaining Estimate: 0.4h ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'. Issue: The RS failed besause of 'already online on this server' and return; The HM can not receive the message and report 'Regions in transition timed out'. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4138) If zookeeper.znode.parent is not specifed explicitly in Client code then HTable object loops continuously waiting for the root region by using /hbase as the base node.
[
https://issues.apache.org/jira/browse/HBASE-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090147#comment-13090147
]
ramkrishna.s.vasudevan commented on HBASE-4138:
---
@Ted,
I debugged and arrived at some points about test failure. Pls check and
correct me if my analysis is wrong.
- In all the failure scenarios we can see that the just before the exception
has occured a new connection was formed. The test cases invoke new HTable(),
in which it flows to
{code}HConnectionManager.getConnection(conf);{code}
- now a new connection is retrieved. The new zookeeper connection tries to
watch the master and root region server node.(MasterAddressTracker.start() and
RootRegionTracker().start()
- In ZKUtil.watchAndCheckExists() api
{code}
Stat s = zkw.getRecoverableZooKeeper().exists(znode, zkw);
LOG.debug(zkw.prefix(Set watcher on existing znode + znode));
return s != null ? true : false;
{code}
We were printing the log msg and then returning. If you see the failure logs
this znode has the proper value like /hbase/master. Now if this had returned
true, the next step
in start() api will be to get the data
{code}byte [] data = ZKUtil.getDataAndWatch(watcher, node);{code}
But if there had been some data then the log
{code}
LOG.debug(zkw.prefix(Retrieved + ((data == null)? 0: data.length) +
{code}
should be present but it is not present and there are no exceptions also.
So ideally what has happened is
{code}ZKUtil.watchAndCheckExists(){code} has returned false. This api will
return false when the node does not exist.
Now what we need to know is in what scenario the node /hbase itself will get
deleted and also what made the new HTable() to create a new connection. (May
be the connection got deleted.)
One more thing we need to add is in HConnectionManager.setupZookeeperTrackers()
{code}masterAddressTracker.start(){code}
if he is not able to establish watch he should throw error. Correct me if am
wrong.
If zookeeper.znode.parent is not specifed explicitly in Client code then
HTable object loops continuously waiting for the root region by using /hbase
as the base node.
---
Key: HBASE-4138
URL: https://issues.apache.org/jira/browse/HBASE-4138
Project: HBase
Issue Type: Bug
Components: client
Affects Versions: 0.90.3
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
Fix For: 0.92.0
Attachments: HBASE-4138_trunk_1.patch, HBASE-4138_trunk_2.patch,
HBASE-4138_trunk_3.patch
Change the zookeeper.znode.parent property (default is /hbase).
Now do not specify this change in the client code.
Use the HTable Object.
The HTable is not able to find the root region and keeps continuously looping.
Find the stack trace:
Object.wait(long) line: not available [native method]
RootRegionTracker(ZooKeeperNodeTracker).blockUntilAvailable(long) line: 122
RootRegionTracker.waitRootRegionLocation(long) line: 73
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[], boolean) line: 578
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[]) line: 558
HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[],
byte[], byte[], boolean, Object) line: 687
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[], boolean) line: 589
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[]) line: 558
HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[],
byte[], byte[], boolean, Object) line: 687
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[], boolean) line: 593
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[]) line: 558
HTable.init(Configuration, byte[]) line: 171
HTable.init(Configuration, String) line: 145
HBaseTest.test() line: 45
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4138) If zookeeper.znode.parent is not specifed explicitly in Client code then HTable object loops continuously waiting for the root region by using /hbase as the base node.
[
https://issues.apache.org/jira/browse/HBASE-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090237#comment-13090237
]
Ted Yu commented on HBASE-4138:
---
@Ramkrishna:
Thanks for the analysis.
masterAddressTracker.start() doesn't have return value. How do you think we
should check for inability of establishing watch ?
I am adding the following log in ZooKeeperNodeTracker.start():
{code}
// It existed but now does not, try again to ensure a watch is set
+ LOG.debug(Try starting again because there is no data from +
node);
{code}
If zookeeper.znode.parent is not specifed explicitly in Client code then
HTable object loops continuously waiting for the root region by using /hbase
as the base node.
---
Key: HBASE-4138
URL: https://issues.apache.org/jira/browse/HBASE-4138
Project: HBase
Issue Type: Bug
Components: client
Affects Versions: 0.90.3
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
Fix For: 0.92.0
Attachments: HBASE-4138_trunk_1.patch, HBASE-4138_trunk_2.patch,
HBASE-4138_trunk_3.patch
Change the zookeeper.znode.parent property (default is /hbase).
Now do not specify this change in the client code.
Use the HTable Object.
The HTable is not able to find the root region and keeps continuously looping.
Find the stack trace:
Object.wait(long) line: not available [native method]
RootRegionTracker(ZooKeeperNodeTracker).blockUntilAvailable(long) line: 122
RootRegionTracker.waitRootRegionLocation(long) line: 73
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[], boolean) line: 578
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[]) line: 558
HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[],
byte[], byte[], boolean, Object) line: 687
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[], boolean) line: 589
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[]) line: 558
HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[],
byte[], byte[], boolean, Object) line: 687
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[], boolean) line: 593
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[]) line: 558
HTable.init(Configuration, byte[]) line: 171
HTable.init(Configuration, String) line: 145
HBaseTest.test() line: 45
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4138) If zookeeper.znode.parent is not specifed explicitly in Client code then HTable object loops continuously waiting for the root region by using /hbase as the base node.
[
https://issues.apache.org/jira/browse/HBASE-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090251#comment-13090251
]
ramkrishna.s.vasudevan commented on HBASE-4138:
---
@Ted
One more thing we can add.
In ZKUtil.watchAndCheckExists() we can make a small change
{code}
if(null != s){
LOG.debug(zkw.prefix(Set watcher on existing znode + znode));
}
else{
LOG.debug(zkw.prefix(znode + znode+ does not exist. No data
retrieved from it.));
}
{code}
Instead of
{code}
LOG.debug(zkw.prefix(Set watcher on existing znode + znode));
return s != null ? true : false;
{code}
This will let us know in future in case of same failure if really the node
existed or not.
If zookeeper.znode.parent is not specifed explicitly in Client code then
HTable object loops continuously waiting for the root region by using /hbase
as the base node.
---
Key: HBASE-4138
URL: https://issues.apache.org/jira/browse/HBASE-4138
Project: HBase
Issue Type: Bug
Components: client
Affects Versions: 0.90.3
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
Fix For: 0.92.0
Attachments: HBASE-4138_trunk_1.patch, HBASE-4138_trunk_2.patch,
HBASE-4138_trunk_3.patch
Change the zookeeper.znode.parent property (default is /hbase).
Now do not specify this change in the client code.
Use the HTable Object.
The HTable is not able to find the root region and keeps continuously looping.
Find the stack trace:
Object.wait(long) line: not available [native method]
RootRegionTracker(ZooKeeperNodeTracker).blockUntilAvailable(long) line: 122
RootRegionTracker.waitRootRegionLocation(long) line: 73
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[], boolean) line: 578
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[]) line: 558
HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[],
byte[], byte[], boolean, Object) line: 687
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[], boolean) line: 589
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[]) line: 558
HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[],
byte[], byte[], boolean, Object) line: 687
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[], boolean) line: 593
HConnectionManager$HConnectionImplementation.locateRegion(byte[],
byte[]) line: 558
HTable.init(Configuration, byte[]) line: 171
HTable.init(Configuration, String) line: 145
HBaseTest.test() line: 45
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4138) If zookeeper.znode.parent is not specifed explicitly in Client code then HTable object loops continuously waiting for the root region by using /hbase as the base node.
[ https://issues.apache.org/jira/browse/HBASE-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090253#comment-13090253 ] ramkrishna.s.vasudevan commented on HBASE-4138: --- Because the existing code first prints a debug msg saying a watcher is set without checking if the node exists or not. This is actually a bit confusing.( I felt so). If zookeeper.znode.parent is not specifed explicitly in Client code then HTable object loops continuously waiting for the root region by using /hbase as the base node. --- Key: HBASE-4138 URL: https://issues.apache.org/jira/browse/HBASE-4138 Project: HBase Issue Type: Bug Components: client Affects Versions: 0.90.3 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.92.0 Attachments: HBASE-4138_trunk_1.patch, HBASE-4138_trunk_2.patch, HBASE-4138_trunk_3.patch Change the zookeeper.znode.parent property (default is /hbase). Now do not specify this change in the client code. Use the HTable Object. The HTable is not able to find the root region and keeps continuously looping. Find the stack trace: Object.wait(long) line: not available [native method] RootRegionTracker(ZooKeeperNodeTracker).blockUntilAvailable(long) line: 122 RootRegionTracker.waitRootRegionLocation(long) line: 73 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 578 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[], byte[], byte[], boolean, Object) line: 687 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 589 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[], byte[], byte[], boolean, Object) line: 687 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 593 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HTable.init(Configuration, byte[]) line: 171 HTable.init(Configuration, String) line: 145 HBaseTest.test() line: 45 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4217) HRS.closeRegion should be able to close regions with only the encoded name
[
https://issues.apache.org/jira/browse/HBASE-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090281#comment-13090281
]
ramkrishna.s.vasudevan commented on HBASE-4217:
---
@Stack
bq. Similar for the new method added to the HRegionInterface (and you don't
need javadoc in HRS since its implementing the Interface so it shoudl inherit
the Interface doc)
{noformat}
+ @Override
+ @QosPriority(priority=HIGH_QOS)
+ public boolean closeRegion(byte[] regionName, boolean zk) throws IOException
{
{noformat}
As in other closeRegion() the javadoc is getting inherited here also.
bq. javadoc needs to better specify that what we are expecting is the encoded
region name
I have done one small modification from the previous patch as per Stack's
suggestion. The new api in HBaseAdmin will take the encodedRegion name along
with server name. If servername is not given then the api will just log and
will not do any. In the previous patch as I had accepted the normal region
name if servername was null was calling the older closeRegion() api.
bq.Do we not have a TestAdmin class already? Should these new tests go in there
instead or into class of their own?
I have added the new testcases to TestAdmin
bq.Oh, what about updating the shell so when you do close_region, it uses your
new method?
I have done this now. Yesterday I missed this part. Pls check this if my way
of adding the new api in shell is correct. If not kindly correct me so that i
can update it.
HRS.closeRegion should be able to close regions with only the encoded name
--
Key: HBASE-4217
URL: https://issues.apache.org/jira/browse/HBASE-4217
Project: HBase
Issue Type: Improvement
Affects Versions: 0.90.4
Reporter: Jean-Daniel Cryans
Assignee: ramkrishna.s.vasudevan
Fix For: 0.92.0
Attachments: HBASE-4217.patch, HBASE-4217_1.patch
We had some sort of an outage this morning due to a few racks losing power,
and some regions were left in the following state:
ERROR: Region UNKNOWN_REGION on sv4r17s9:60020,
key=e32bbe1f48c9b3633c557dc0291b90a3, not on HDFS or in META but deployed on
sv4r17s9:60020
That region was deleted by the master but the region server never got the
memo. Right now there's no way to force close it because HRS.closeRegion
requires an HRI and the only way to create one is to get it from .META. which
in our case doesn't contain a row for that region. Basically we have to wait
until that server is dead to get rid of the region and make hbck happy.
The required change is to have closeRegion accept an encoded name in both HBA
(when the RS address is provided) and HRS since it's able to find it anyways
from it's list of live regions.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4124) ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'.
[
https://issues.apache.org/jira/browse/HBASE-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090298#comment-13090298
]
ramkrishna.s.vasudevan commented on HBASE-4124:
---
@Gao
Correct me if am wrong. I can understand the intention behind the logic.
{code}
+ RegionTransitionData data = ZKAssign.getData(watcher,
regionInfo.getEncodedName());
+
+ //When zk node has been updated by a living server, we consider that
this region server is handling it.
+ //So we should skip it and process it in processRegionsInTransition.
+ if (data != null data.getServerName() != null
+serverManager.isServerOnline(data.getServerName())){
+ LOG.info(The region + regionInfo.getEncodedName() +
+is processing by + data.getServerName());
+continue;
+ }
{code}
But if as part of rebuildUserRegions() the master finds a server to be dead and
adds those RS to dead servers and also u said the master was killed.
How come we have a dead RS if we dont kill the RS and if the master is also
killed how can the regions be assigned to some other RS (how can the state
change in ZK for that region node).
May be am not understanding something. If you can explain this it will help me
in Timeoutmonitor.
Rest looks fine.
ZK restarted while assigning a region, new active HM re-assign it but the RS
warned 'already online on this server'.
Key: HBASE-4124
URL: https://issues.apache.org/jira/browse/HBASE-4124
Project: HBase
Issue Type: Bug
Components: master
Reporter: fulin wang
Assignee: gaojinchao
Fix For: 0.90.5
Attachments: HBASE-4124_Branch90V1_trial.patch,
HBASE-4124_Branch90V2.patch, HBASE-4124_Branch90V3.patch, log.txt
Original Estimate: 0.4h
Remaining Estimate: 0.4h
ZK restarted while assigning a region, new active HM re-assign it but the RS
warned 'already online on this server'.
Issue:
The RS failed besause of 'already online on this server' and return; The HM
can not receive the message and report 'Regions in transition timed out'.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4227) Modify the webUI so that default values of column families are not shown
[ https://issues.apache.org/jira/browse/HBASE-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090309#comment-13090309 ] nileema shingte commented on HBASE-4227: I will create a patch for this with a describe 'table_name' and describe_details 'table_name' (former will print only non-default values and latter will print all) Modify the webUI so that default values of column families are not shown Key: HBASE-4227 URL: https://issues.apache.org/jira/browse/HBASE-4227 Project: HBase Issue Type: Improvement Reporter: Nicolas Spiegelberg Assignee: nileema shingte Priority: Minor Fix For: 0.92.0 Attachments: HBASE-4227.patch, HBASE-4227.patch With the introduction of online schema changes, it will become more advantageous to put configuration knobs at the column family level vs global configuration settings. This will create a nasty web UI experience for showing table properties unless we default to showing the custom values instead of all values. It's on the table if we want to modify the shell's 'describe' method as well. scan '.META.' should definitely return the full properties however. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4138) If zookeeper.znode.parent is not specifed explicitly in Client code then HTable object loops continuously waiting for the root region by using /hbase as the base node.
[ https://issues.apache.org/jira/browse/HBASE-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090315#comment-13090315 ] Hudson commented on HBASE-4138: --- Integrated in HBase-TRUNK #2139 (See [https://builds.apache.org/job/HBase-TRUNK/2139/]) HBASE-4138 Add debug log in ZooKeeperNodeTracker.start() tedyu : Files : * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperNodeTracker.java If zookeeper.znode.parent is not specifed explicitly in Client code then HTable object loops continuously waiting for the root region by using /hbase as the base node. --- Key: HBASE-4138 URL: https://issues.apache.org/jira/browse/HBASE-4138 Project: HBase Issue Type: Bug Components: client Affects Versions: 0.90.3 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.92.0 Attachments: HBASE-4138_trunk_1.patch, HBASE-4138_trunk_2.patch, HBASE-4138_trunk_3.patch Change the zookeeper.znode.parent property (default is /hbase). Now do not specify this change in the client code. Use the HTable Object. The HTable is not able to find the root region and keeps continuously looping. Find the stack trace: Object.wait(long) line: not available [native method] RootRegionTracker(ZooKeeperNodeTracker).blockUntilAvailable(long) line: 122 RootRegionTracker.waitRootRegionLocation(long) line: 73 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 578 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[], byte[], byte[], boolean, Object) line: 687 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 589 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[], byte[], byte[], boolean, Object) line: 687 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 593 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HTable.init(Configuration, byte[]) line: 171 HTable.init(Configuration, String) line: 145 HBaseTest.test() line: 45 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-4195) Possible inconsistency in a memstore read after a reseek, possible performance improvement
[
https://issues.apache.org/jira/browse/HBASE-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nkeywal reassigned HBASE-4195:
--
Assignee: nkeywal
Possible inconsistency in a memstore read after a reseek, possible
performance improvement
--
Key: HBASE-4195
URL: https://issues.apache.org/jira/browse/HBASE-4195
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.90.4
Environment: all
Reporter: nkeywal
Assignee: nkeywal
Priority: Critical
This follows the dicussion around HBASE-3855, and the random errors (20%
failure on trunk) on the unit test
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
I saw some points related to numIterReseek, used in the
MemStoreScanner#getNext (line 690):
{noformat}679 protected KeyValue getNext(Iterator it) {
680 KeyValue ret = null;
681 long readPoint = ReadWriteConsistencyControl.getThreadReadPoint();
682 //DebugPrint.println( MS@ + hashCode() + : threadpoint = +
readPoint);
683
684 while (ret == null it.hasNext()) {
685 KeyValue v = it.next();
686 if (v.getMemstoreTS() = readPoint) {
687 // keep it.
688 ret = v;
689 }
690 numIterReseek--;
691 if (numIterReseek == 0) {
692 break;
693}
694 }
695 return ret;
696 }{noformat}
This function is called by seek, reseek, and next. The numIterReseek is only
usefull for reseek.
There are some issues, I am not totally sure it's the root cause of the test
case error, but it could explain partly the randomness of the error, and one
point is for sure a bug.
1) In getNext, numIterReseek is decreased, then compared to zero. The seek
function sets numIterReseek to zero before calling getNext. It means that the
value will be actually negative, hence the test will always fail, and the
loop will continue. It is the expected behaviour, but it's quite smart.
2) In reseek, numIterReseek is not set between the loops on the two
iterators. If the numIterReseek is equals to zero after the loop on the first
one, the loop on the second one will never call seek, as numIterReseek will
be negative.
3) Still in reseek, the test to call seek is (kvsetNextRow == null
numIterReseek == 0). In other words, if kvsetNextRow is not null when
numIterReseek equals zero, numIterReseek will start to be negative at the
next iteration and seek will never be called.
4) You can have side effects if reseek ends with a numIterReseek 0: the
following calls to the next function will decrease numIterReseek to zero,
and getNext will break instead of continuing the loop. As a result, later
calls to next() may return null or not depending on how is configured the
default value for numIterReseek.
To check if the issue comes from point 4, you can set the numIterReseek to
zero before returning in reseek:
{noformat} numIterReseek = 0;
return (kvsetNextRow != null || snapshotNextRow != null);
}{noformat}
On my env, on trunk, it seems to work, but as it's random I am not really
sure. I also had to modify the test (I added a loop) to make it fails more
often, the original test was working quite well here.
It has to be confirmed that this totally fix (it could be partial or
unrelated)
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
before implementing a complete solution.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4195) Possible inconsistency in a memstore read after a reseek, possible performance improvement
[
https://issues.apache.org/jira/browse/HBASE-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090324#comment-13090324
]
nkeywal commented on HBASE-4195:
I tested 2 cases:
1) The current implementation
2) A new one (reusing the first one logic without calling seek).
Times (for public void TestHRegion#testWritesWhileGetting()) are, on a
virtualized environment:
Current - 26s
Proposed - 13s
It's a little bit suprising to have a so good result, but it could be explained
by the behaviour when the counter gets negative: we can have both a lot of
iterations on the list + a call to seek. There is also a lot of gc related
time, so it will depends on the memory available.
But as a conclusion, it seems that it's interesting to use directly the search
on the sublist. I will do a patch on the trunk.
Possible inconsistency in a memstore read after a reseek, possible
performance improvement
--
Key: HBASE-4195
URL: https://issues.apache.org/jira/browse/HBASE-4195
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.90.4
Environment: all
Reporter: nkeywal
Priority: Critical
This follows the dicussion around HBASE-3855, and the random errors (20%
failure on trunk) on the unit test
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
I saw some points related to numIterReseek, used in the
MemStoreScanner#getNext (line 690):
{noformat}679 protected KeyValue getNext(Iterator it) {
680 KeyValue ret = null;
681 long readPoint = ReadWriteConsistencyControl.getThreadReadPoint();
682 //DebugPrint.println( MS@ + hashCode() + : threadpoint = +
readPoint);
683
684 while (ret == null it.hasNext()) {
685 KeyValue v = it.next();
686 if (v.getMemstoreTS() = readPoint) {
687 // keep it.
688 ret = v;
689 }
690 numIterReseek--;
691 if (numIterReseek == 0) {
692 break;
693}
694 }
695 return ret;
696 }{noformat}
This function is called by seek, reseek, and next. The numIterReseek is only
usefull for reseek.
There are some issues, I am not totally sure it's the root cause of the test
case error, but it could explain partly the randomness of the error, and one
point is for sure a bug.
1) In getNext, numIterReseek is decreased, then compared to zero. The seek
function sets numIterReseek to zero before calling getNext. It means that the
value will be actually negative, hence the test will always fail, and the
loop will continue. It is the expected behaviour, but it's quite smart.
2) In reseek, numIterReseek is not set between the loops on the two
iterators. If the numIterReseek is equals to zero after the loop on the first
one, the loop on the second one will never call seek, as numIterReseek will
be negative.
3) Still in reseek, the test to call seek is (kvsetNextRow == null
numIterReseek == 0). In other words, if kvsetNextRow is not null when
numIterReseek equals zero, numIterReseek will start to be negative at the
next iteration and seek will never be called.
4) You can have side effects if reseek ends with a numIterReseek 0: the
following calls to the next function will decrease numIterReseek to zero,
and getNext will break instead of continuing the loop. As a result, later
calls to next() may return null or not depending on how is configured the
default value for numIterReseek.
To check if the issue comes from point 4, you can set the numIterReseek to
zero before returning in reseek:
{noformat} numIterReseek = 0;
return (kvsetNextRow != null || snapshotNextRow != null);
}{noformat}
On my env, on trunk, it seems to work, but as it's random I am not really
sure. I also had to modify the test (I added a loop) to make it fails more
often, the original test was working quite well here.
It has to be confirmed that this totally fix (it could be partial or
unrelated)
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
before implementing a complete solution.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4242) Add documentation for HBASE-4071
[ https://issues.apache.org/jira/browse/HBASE-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090329#comment-13090329 ] Lars Hofhansl commented on HBASE-4242: -- Thanks Stack. Add documentation for HBASE-4071 Key: HBASE-4242 URL: https://issues.apache.org/jira/browse/HBASE-4242 Project: HBase Issue Type: Sub-task Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Priority: Minor Fix For: 0.92.0 Attachments: 4242.txt Add documentation for min versions to the HBase book. I'll add patch soon. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4138) If zookeeper.znode.parent is not specifed explicitly in Client code then HTable object loops continuously waiting for the root region by using /hbase as the base node.
[ https://issues.apache.org/jira/browse/HBASE-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090335#comment-13090335 ] ramkrishna.s.vasudevan commented on HBASE-4138: --- @Ted Thanks for adding the change ZKUtil.java also. What could be the reason for the node not to exist and why was a new connection established? These 2 we may have to figure out exactly. If zookeeper.znode.parent is not specifed explicitly in Client code then HTable object loops continuously waiting for the root region by using /hbase as the base node. --- Key: HBASE-4138 URL: https://issues.apache.org/jira/browse/HBASE-4138 Project: HBase Issue Type: Bug Components: client Affects Versions: 0.90.3 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.92.0 Attachments: HBASE-4138_trunk_1.patch, HBASE-4138_trunk_2.patch, HBASE-4138_trunk_3.patch Change the zookeeper.znode.parent property (default is /hbase). Now do not specify this change in the client code. Use the HTable Object. The HTable is not able to find the root region and keeps continuously looping. Find the stack trace: Object.wait(long) line: not available [native method] RootRegionTracker(ZooKeeperNodeTracker).blockUntilAvailable(long) line: 122 RootRegionTracker.waitRootRegionLocation(long) line: 73 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 578 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[], byte[], byte[], boolean, Object) line: 687 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 589 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[], byte[], byte[], boolean, Object) line: 687 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 593 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HTable.init(Configuration, byte[]) line: 171 HTable.init(Configuration, String) line: 145 HBaseTest.test() line: 45 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4176) Exposing HBase Filters to the Thrift API
[ https://issues.apache.org/jira/browse/HBASE-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anirudh Todi updated HBASE-4176: Attachment: HBASE-4176(2).patch Hi Stack, Todd, Ted, Li - thanks for reviewing and committing my Filter Language diff! I am attaching another patch - HBASE-4176(2).patch which includes a couple of enhancements. - It enables a show_filters command from the HBase shell that lists the filters from the shell - It moves the creation of the HashMaps into a static block - so that they aren't initialized every time an RPC call is made Exposing HBase Filters to the Thrift API Key: HBASE-4176 URL: https://issues.apache.org/jira/browse/HBASE-4176 Project: HBase Issue Type: Improvement Components: thrift Reporter: Anirudh Todi Assignee: Anirudh Todi Priority: Minor Fix For: 0.92.0 Attachments: Filter Language (3).xml, Filter Language(2).docx, Filter Language(2).xml, Filter Language(3).docx, Filter Language.docx, HBASE-4176(2).patch, HBASE-4176.patch, book.xml, book2.html, book2.xml Currently, to use any of the filters, one has to explicitly add a scanner for the filter in the Thrift API making it messy and long. With this patch, I am trying to add support for all the filters in a clean way. The user specifies a filter via a string. The string is parsed on the server to construct the filter. More information can be found in the attached document named Filter Language This patch is trying to extend and further the progress made by the patches in the HBASE-1744 JIRA (https://issues.apache.org/jira/browse/HBASE-1744) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4217) HRS.closeRegion should be able to close regions with only the encoded name
[ https://issues.apache.org/jira/browse/HBASE-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-4217: -- Status: Patch Available (was: Open) HRS.closeRegion should be able to close regions with only the encoded name -- Key: HBASE-4217 URL: https://issues.apache.org/jira/browse/HBASE-4217 Project: HBase Issue Type: Improvement Affects Versions: 0.90.4 Reporter: Jean-Daniel Cryans Assignee: ramkrishna.s.vasudevan Fix For: 0.92.0 Attachments: HBASE-4217.patch, HBASE-4217_1.patch, HBASE-4217_2.patch We had some sort of an outage this morning due to a few racks losing power, and some regions were left in the following state: ERROR: Region UNKNOWN_REGION on sv4r17s9:60020, key=e32bbe1f48c9b3633c557dc0291b90a3, not on HDFS or in META but deployed on sv4r17s9:60020 That region was deleted by the master but the region server never got the memo. Right now there's no way to force close it because HRS.closeRegion requires an HRI and the only way to create one is to get it from .META. which in our case doesn't contain a row for that region. Basically we have to wait until that server is dead to get rid of the region and make hbck happy. The required change is to have closeRegion accept an encoded name in both HBA (when the RS address is provided) and HRS since it's able to find it anyways from it's list of live regions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4217) HRS.closeRegion should be able to close regions with only the encoded name
[ https://issues.apache.org/jira/browse/HBASE-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-4217: -- Status: Open (was: Patch Available) HRS.closeRegion should be able to close regions with only the encoded name -- Key: HBASE-4217 URL: https://issues.apache.org/jira/browse/HBASE-4217 Project: HBase Issue Type: Improvement Affects Versions: 0.90.4 Reporter: Jean-Daniel Cryans Assignee: ramkrishna.s.vasudevan Fix For: 0.92.0 Attachments: HBASE-4217.patch, HBASE-4217_1.patch, HBASE-4217_2.patch We had some sort of an outage this morning due to a few racks losing power, and some regions were left in the following state: ERROR: Region UNKNOWN_REGION on sv4r17s9:60020, key=e32bbe1f48c9b3633c557dc0291b90a3, not on HDFS or in META but deployed on sv4r17s9:60020 That region was deleted by the master but the region server never got the memo. Right now there's no way to force close it because HRS.closeRegion requires an HRI and the only way to create one is to get it from .META. which in our case doesn't contain a row for that region. Basically we have to wait until that server is dead to get rid of the region and make hbck happy. The required change is to have closeRegion accept an encoded name in both HBA (when the RS address is provided) and HRS since it's able to find it anyways from it's list of live regions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4176) Exposing HBase Filters to the Thrift API
[ https://issues.apache.org/jira/browse/HBASE-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090349#comment-13090349 ] Ted Yu commented on HBASE-4176: --- This issue has been resolved. Please open a new JIRA and attach the patch there. Thanks Exposing HBase Filters to the Thrift API Key: HBASE-4176 URL: https://issues.apache.org/jira/browse/HBASE-4176 Project: HBase Issue Type: Improvement Components: thrift Reporter: Anirudh Todi Assignee: Anirudh Todi Priority: Minor Fix For: 0.92.0 Attachments: Filter Language (3).xml, Filter Language(2).docx, Filter Language(2).xml, Filter Language(3).docx, Filter Language.docx, HBASE-4176(2).patch, HBASE-4176.patch, book.xml, book2.html, book2.xml Currently, to use any of the filters, one has to explicitly add a scanner for the filter in the Thrift API making it messy and long. With this patch, I am trying to add support for all the filters in a clean way. The user specifies a filter via a string. The string is parsed on the server to construct the filter. More information can be found in the attached document named Filter Language This patch is trying to extend and further the progress made by the patches in the HBASE-1744 JIRA (https://issues.apache.org/jira/browse/HBASE-1744) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-4248) HBASE-4176 enabled a Filter Language to expose HBase filters to the Thrift API. Here I make a couple of improvements to the that patch
HBASE-4176 enabled a Filter Language to expose HBase filters to the Thrift API. Here I make a couple of improvements to the that patch -- Key: HBASE-4248 URL: https://issues.apache.org/jira/browse/HBASE-4248 Project: HBase Issue Type: Improvement Reporter: Anirudh Todi Assignee: Anirudh Todi Priority: Minor Attachments: HBASE-4248.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4248) Enhancements for Filter Language exposing HBase filters through the Thrift API
[ https://issues.apache.org/jira/browse/HBASE-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anirudh Todi updated HBASE-4248: Description: HBASE-4176 enabled a Filter Language to expose HBase filters to the Thrift API. Here I make a couple of improvements to the that patch: - Enables a show_filters command from the HBase shell that lists the filters from the shell - Moves the creation of the HashMaps into a static block - so that they aren't initialized every time an RPC call is made was:HBASE-4176 enabled a Filter Language to expose HBase filters to the Thrift API. Here I make a couple of improvements to the that patch Enhancements for Filter Language exposing HBase filters through the Thrift API -- Key: HBASE-4248 URL: https://issues.apache.org/jira/browse/HBASE-4248 Project: HBase Issue Type: Improvement Reporter: Anirudh Todi Assignee: Anirudh Todi Priority: Minor Attachments: HBASE-4248.patch HBASE-4176 enabled a Filter Language to expose HBase filters to the Thrift API. Here I make a couple of improvements to the that patch: - Enables a show_filters command from the HBase shell that lists the filters from the shell - Moves the creation of the HashMaps into a static block - so that they aren't initialized every time an RPC call is made -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4248) Enhancements for Filter Language exposing HBase filters through the Thrift API
[
https://issues.apache.org/jira/browse/HBASE-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090360#comment-13090360
]
Ted Yu commented on HBASE-4248:
---
Please fix year:
{code}
+# Copyright 2010 The Apache Software Foundation
{code}
Enhancements for Filter Language exposing HBase filters through the Thrift API
--
Key: HBASE-4248
URL: https://issues.apache.org/jira/browse/HBASE-4248
Project: HBase
Issue Type: Improvement
Reporter: Anirudh Todi
Assignee: Anirudh Todi
Priority: Minor
Attachments: HBASE-4248.patch
HBASE-4176 enabled a Filter Language to expose HBase filters to the Thrift
API. Here I make a couple of improvements to the that patch:
- Enables a show_filters command from the HBase shell that lists the
filters from the shell
- Moves the creation of the HashMaps into a static block - so that they
aren't initialized every time an RPC call is made
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4248) Enhancements for Filter Language exposing HBase filters through the Thrift API
[ https://issues.apache.org/jira/browse/HBASE-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anirudh Todi updated HBASE-4248: Attachment: HBASE-4248(3).patch - Removed reference to the internal wiki Enhancements for Filter Language exposing HBase filters through the Thrift API -- Key: HBASE-4248 URL: https://issues.apache.org/jira/browse/HBASE-4248 Project: HBase Issue Type: Improvement Reporter: Anirudh Todi Assignee: Anirudh Todi Priority: Minor Attachments: HBASE-4248(2).patch, HBASE-4248(3).patch, HBASE-4248.patch HBASE-4176 enabled a Filter Language to expose HBase filters to the Thrift API. Here I make a couple of improvements to the that patch: - Enables a show_filters command from the HBase shell that lists the filters from the shell - Moves the creation of the HashMaps into a static block - so that they aren't initialized every time an RPC call is made -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4138) If zookeeper.znode.parent is not specifed explicitly in Client code then HTable object loops continuously waiting for the root region by using /hbase as the base node.
[ https://issues.apache.org/jira/browse/HBASE-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090370#comment-13090370 ] Hudson commented on HBASE-4138: --- Integrated in HBase-TRUNK-on-Hadoop-23 #4 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-23/4/]) HBASE-4138 Change debug log in ZKUtil.watchAndCheckExists() HBASE-4138 Add debug log in ZooKeeperNodeTracker.start() tedyu : Files : * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKUtil.java tedyu : Files : * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperNodeTracker.java If zookeeper.znode.parent is not specifed explicitly in Client code then HTable object loops continuously waiting for the root region by using /hbase as the base node. --- Key: HBASE-4138 URL: https://issues.apache.org/jira/browse/HBASE-4138 Project: HBase Issue Type: Bug Components: client Affects Versions: 0.90.3 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.92.0 Attachments: HBASE-4138_trunk_1.patch, HBASE-4138_trunk_2.patch, HBASE-4138_trunk_3.patch Change the zookeeper.znode.parent property (default is /hbase). Now do not specify this change in the client code. Use the HTable Object. The HTable is not able to find the root region and keeps continuously looping. Find the stack trace: Object.wait(long) line: not available [native method] RootRegionTracker(ZooKeeperNodeTracker).blockUntilAvailable(long) line: 122 RootRegionTracker.waitRootRegionLocation(long) line: 73 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 578 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[], byte[], byte[], boolean, Object) line: 687 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 589 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HConnectionManager$HConnectionImplementation.locateRegionInMeta(byte[], byte[], byte[], boolean, Object) line: 687 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[], boolean) line: 593 HConnectionManager$HConnectionImplementation.locateRegion(byte[], byte[]) line: 558 HTable.init(Configuration, byte[]) line: 171 HTable.init(Configuration, String) line: 145 HBaseTest.test() line: 45 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4195) Possible inconsistency in a memstore read after a reseek, possible performance improvement
[
https://issues.apache.org/jira/browse/HBASE-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nkeywal updated HBASE-4195:
---
Attachment: 20110824_4195_TestHRegion.patch
20110824_4195_MemStore.patch
TestHRegion: added log to help understand where the problem comes from +
modification of the put thread to insert strings (easier to read).
MemStore: implementation of reseek by using sublist set in seek
Possible inconsistency in a memstore read after a reseek, possible
performance improvement
--
Key: HBASE-4195
URL: https://issues.apache.org/jira/browse/HBASE-4195
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.90.4
Environment: all
Reporter: nkeywal
Assignee: nkeywal
Priority: Critical
Attachments: 20110824_4195_MemStore.patch,
20110824_4195_TestHRegion.patch
This follows the dicussion around HBASE-3855, and the random errors (20%
failure on trunk) on the unit test
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
I saw some points related to numIterReseek, used in the
MemStoreScanner#getNext (line 690):
{noformat}679 protected KeyValue getNext(Iterator it) {
680 KeyValue ret = null;
681 long readPoint = ReadWriteConsistencyControl.getThreadReadPoint();
682 //DebugPrint.println( MS@ + hashCode() + : threadpoint = +
readPoint);
683
684 while (ret == null it.hasNext()) {
685 KeyValue v = it.next();
686 if (v.getMemstoreTS() = readPoint) {
687 // keep it.
688 ret = v;
689 }
690 numIterReseek--;
691 if (numIterReseek == 0) {
692 break;
693}
694 }
695 return ret;
696 }{noformat}
This function is called by seek, reseek, and next. The numIterReseek is only
usefull for reseek.
There are some issues, I am not totally sure it's the root cause of the test
case error, but it could explain partly the randomness of the error, and one
point is for sure a bug.
1) In getNext, numIterReseek is decreased, then compared to zero. The seek
function sets numIterReseek to zero before calling getNext. It means that the
value will be actually negative, hence the test will always fail, and the
loop will continue. It is the expected behaviour, but it's quite smart.
2) In reseek, numIterReseek is not set between the loops on the two
iterators. If the numIterReseek is equals to zero after the loop on the first
one, the loop on the second one will never call seek, as numIterReseek will
be negative.
3) Still in reseek, the test to call seek is (kvsetNextRow == null
numIterReseek == 0). In other words, if kvsetNextRow is not null when
numIterReseek equals zero, numIterReseek will start to be negative at the
next iteration and seek will never be called.
4) You can have side effects if reseek ends with a numIterReseek 0: the
following calls to the next function will decrease numIterReseek to zero,
and getNext will break instead of continuing the loop. As a result, later
calls to next() may return null or not depending on how is configured the
default value for numIterReseek.
To check if the issue comes from point 4, you can set the numIterReseek to
zero before returning in reseek:
{noformat} numIterReseek = 0;
return (kvsetNextRow != null || snapshotNextRow != null);
}{noformat}
On my env, on trunk, it seems to work, but as it's random I am not really
sure. I also had to modify the test (I added a loop) to make it fails more
often, the original test was working quite well here.
It has to be confirmed that this totally fix (it could be partial or
unrelated)
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
before implementing a complete solution.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4007) distributed log splitting can get indefinitely stuck
[ https://issues.apache.org/jira/browse/HBASE-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash Khemani updated HBASE-4007: --- Status: Patch Available (was: Open) fixes (1) buildup of RESCAN zookeeper nodes in the event that all the regionservers are down (2) a bug in tracking when the last RESCAN node was created which could lead to too frequent RESCAN node creation (3) if master/splitlogmanager fails to complete the task handed over by a region-server/worker then keep retrying indefinitely (4) if a regionserver/worker dies then ensure that all its tasks are resubmitted distributed log splitting can get indefinitely stuck Key: HBASE-4007 URL: https://issues.apache.org/jira/browse/HBASE-4007 Project: HBase Issue Type: Bug Reporter: Prakash Khemani Assignee: Prakash Khemani After the configured number of retries SplitLogManager is not going to resubmit log-split tasks. In this situation even if the splitLogWorker that owns the task dies the task will not get resubmitted. When a regionserver goes away then all the split-log tasks that it owned should be resubmitted by the SplitLogMaster. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4007) distributed log splitting can get indefinitely stuck
[ https://issues.apache.org/jira/browse/HBASE-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash Khemani updated HBASE-4007: --- Status: Open (was: Patch Available) distributed log splitting can get indefinitely stuck Key: HBASE-4007 URL: https://issues.apache.org/jira/browse/HBASE-4007 Project: HBase Issue Type: Bug Reporter: Prakash Khemani Assignee: Prakash Khemani After the configured number of retries SplitLogManager is not going to resubmit log-split tasks. In this situation even if the splitLogWorker that owns the task dies the task will not get resubmitted. When a regionserver goes away then all the split-log tasks that it owned should be resubmitted by the SplitLogMaster. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4007) distributed log splitting can get indefinitely stuck
[ https://issues.apache.org/jira/browse/HBASE-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash Khemani updated HBASE-4007: --- Attachment: 0001-HBASE-4007-distributed-log-splitting-can-get-indefin.patch patch distributed log splitting can get indefinitely stuck Key: HBASE-4007 URL: https://issues.apache.org/jira/browse/HBASE-4007 Project: HBase Issue Type: Bug Reporter: Prakash Khemani Assignee: Prakash Khemani Attachments: 0001-HBASE-4007-distributed-log-splitting-can-get-indefin.patch After the configured number of retries SplitLogManager is not going to resubmit log-split tasks. In this situation even if the splitLogWorker that owns the task dies the task will not get resubmitted. When a regionserver goes away then all the split-log tasks that it owned should be resubmitted by the SplitLogMaster. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-4241: - Attachment: 4241.txt Here's a sketch for a patch. Basically the KVs of the memstore's snapshot are wrapped in a scanner and then passed for a new StoreScanner. So we use the same logic as in compactions here, which is good. The reasoning why this is correct goes as follows: If maxVersion=N and we find more than N versions in the memstore we safely avoid writing all further versions. Same for minVersions, if minversions=N and we find at least N versions in the memstore we can avoid writing all further expired versions. Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Sub-task Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Priority: Minor Attachments: 4241.txt As discussed with with Jon, there is room for improvement in how the memstore is flushed to disk. Currently only expired KVs are pruned before flushing, but we can also prune versions if we find at least maxVersions versions in the memstore. The same holds for the new minversion feature: If we find at least minVersion versions in the store we can remove all further versions that are expired. Generally we should use the same mechanism here that is used for Compaction. I.e. StoreScanner. We only need to add a scanner to Memstore that can scan along the current snapshot. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-4241: - Priority: Major (was: Minor) Changed to major as I think this is an important optimization. Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Sub-task Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Attachments: 4241.txt As discussed with with Jon, there is room for improvement in how the memstore is flushed to disk. Currently only expired KVs are pruned before flushing, but we can also prune versions if we find at least maxVersions versions in the memstore. The same holds for the new minversion feature: If we find at least minVersion versions in the store we can remove all further versions that are expired. Generally we should use the same mechanism here that is used for Compaction. I.e. StoreScanner. We only need to add a scanner to Memstore that can scan along the current snapshot. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090426#comment-13090426 ] Lars Hofhansl commented on HBASE-4241: -- Might as well keep using this one... Please let me know what you think of the patch in general, then I'll clean it up, add my local unitests, and post for formal review. Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Sub-task Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Priority: Minor Attachments: 4241.txt As discussed with with Jon, there is room for improvement in how the memstore is flushed to disk. Currently only expired KVs are pruned before flushing, but we can also prune versions if we find at least maxVersions versions in the memstore. The same holds for the new minversion feature: If we find at least minVersion versions in the store we can remove all further versions that are expired. Generally we should use the same mechanism here that is used for Compaction. I.e. StoreScanner. We only need to add a scanner to Memstore that can scan along the current snapshot. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl reassigned HBASE-4241: Assignee: Lars Hofhansl Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Sub-task Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Attachments: 4241.txt As discussed with with Jon, there is room for improvement in how the memstore is flushed to disk. Currently only expired KVs are pruned before flushing, but we can also prune versions if we find at least maxVersions versions in the memstore. The same holds for the new minversion feature: If we find at least minVersion versions in the store we can remove all further versions that are expired. Generally we should use the same mechanism here that is used for Compaction. I.e. StoreScanner. We only need to add a scanner to Memstore that can scan along the current snapshot. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[
https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090437#comment-13090437
]
Ted Yu commented on HBASE-4241:
---
Interesting idea.
{code}
+/**
+ * Utility scanner that can wrap a collection and pretend to
+ * be a KeyValueScanner.
+ */
+public class ScannerWrapper implements KeyValueScanner {
{code}
This class might be used elsewhere.
How about naming it CollectionBackedScanner ?
Optimize flushing of the Store cache for max versions and (new) min versions
Key: HBASE-4241
URL: https://issues.apache.org/jira/browse/HBASE-4241
Project: HBase
Issue Type: Sub-task
Components: regionserver
Affects Versions: 0.92.0
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Attachments: 4241.txt
As discussed with with Jon, there is room for improvement in how the memstore
is flushed to disk.
Currently only expired KVs are pruned before flushing, but we can also prune
versions if we find at least maxVersions versions in the memstore.
The same holds for the new minversion feature: If we find at least minVersion
versions in the store we can remove all further versions that are expired.
Generally we should use the same mechanism here that is used for Compaction.
I.e. StoreScanner. We only need to add a scanner to Memstore that can scan
along the current snapshot.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090439#comment-13090439 ] Lars Hofhansl commented on HBASE-4241: -- I like that. I had been struggling with a name for it. Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Sub-task Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Attachments: 4241.txt As discussed with with Jon, there is room for improvement in how the memstore is flushed to disk. Currently only expired KVs are pruned before flushing, but we can also prune versions if we find at least maxVersions versions in the memstore. The same holds for the new minversion feature: If we find at least minVersion versions in the store we can remove all further versions that are expired. Generally we should use the same mechanism here that is used for Compaction. I.e. StoreScanner. We only need to add a scanner to Memstore that can scan along the current snapshot. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-3900) Expose progress of a major compaction in UI and/or in shell
[ https://issues.apache.org/jira/browse/HBASE-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Anderson updated HBASE-3900: - Attachment: (was: 3900.patch) Expose progress of a major compaction in UI and/or in shell --- Key: HBASE-3900 URL: https://issues.apache.org/jira/browse/HBASE-3900 Project: HBase Issue Type: Task Reporter: stack Labels: patch Attachments: HBASE-3900.patch A general recommendation is to turn off major compactions and run them externally only currently the only way to follow progress of a major compaction is by study of regionserver logs. Add a feature that gives a percentage complete of major compaction up in the UI or in shell. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4071) Data GC: Remove all versions TTL EXCEPT the last written version
[
https://issues.apache.org/jira/browse/HBASE-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090449#comment-13090449
]
Ted Yu commented on HBASE-4071:
---
Here is the addendum I committed:
{code}
Index: src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
===
--- src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
(revision 1161190)
+++ src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
(working copy)
@@ -1734,7 +1734,7 @@
public static final long FIXED_OVERHEAD = ClassSize.align(
ClassSize.OBJECT + (15 * ClassSize.REFERENCE) +
(8 * Bytes.SIZEOF_LONG) + (1 * Bytes.SIZEOF_DOUBLE) +
- (4 * Bytes.SIZEOF_INT) + (3 * Bytes.SIZEOF_BOOLEAN));
+ (5 * Bytes.SIZEOF_INT) + (3 * Bytes.SIZEOF_BOOLEAN));
public static final long DEEP_OVERHEAD = ClassSize.align(FIXED_OVERHEAD +
ClassSize.OBJECT + ClassSize.REENTRANT_LOCK +
{code}
Forgetting to update FIXED_OVERHEAD is very common.
Data GC: Remove all versions TTL EXCEPT the last written version
--
Key: HBASE-4071
URL: https://issues.apache.org/jira/browse/HBASE-4071
Project: HBase
Issue Type: New Feature
Reporter: stack
Assignee: Lars Hofhansl
Fix For: 0.92.0
Attachments: MinVersions.diff
We were chatting today about our backup cluster. What we want is to be able
to restore the dataset from any point of time but only within a limited
timeframe -- say one week. Thereafter, if the versions are older than one
week, rather than as we do with TTL where we let go of all versions older
than TTL, instead, let go of all versions EXCEPT the last one written. So,
its like versions==1 when TTL one week. We want to allow that if an error
is caught within a week of its happening -- user mistakenly removes a
critical table -- then we'll be able to restore up the the moment just before
catastrophe hit otherwise, we keep one version only.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4071) Data GC: Remove all versions TTL EXCEPT the last written version
[ https://issues.apache.org/jira/browse/HBASE-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090459#comment-13090459 ] Hbase Build Acct commented on HBASE-4071: - thank you Data GC: Remove all versions TTL EXCEPT the last written version -- Key: HBASE-4071 URL: https://issues.apache.org/jira/browse/HBASE-4071 Project: HBase Issue Type: New Feature Reporter: stack Assignee: Lars Hofhansl Fix For: 0.92.0 Attachments: MinVersions.diff We were chatting today about our backup cluster. What we want is to be able to restore the dataset from any point of time but only within a limited timeframe -- say one week. Thereafter, if the versions are older than one week, rather than as we do with TTL where we let go of all versions older than TTL, instead, let go of all versions EXCEPT the last one written. So, its like versions==1 when TTL one week. We want to allow that if an error is caught within a week of its happening -- user mistakenly removes a critical table -- then we'll be able to restore up the the moment just before catastrophe hit otherwise, we keep one version only. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4071) Data GC: Remove all versions TTL EXCEPT the last written version
[ https://issues.apache.org/jira/browse/HBASE-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090465#comment-13090465 ] Lars Hofhansl commented on HBASE-4071: -- Thanks Ted! Data GC: Remove all versions TTL EXCEPT the last written version -- Key: HBASE-4071 URL: https://issues.apache.org/jira/browse/HBASE-4071 Project: HBase Issue Type: New Feature Reporter: stack Assignee: Lars Hofhansl Fix For: 0.92.0 Attachments: MinVersions.diff We were chatting today about our backup cluster. What we want is to be able to restore the dataset from any point of time but only within a limited timeframe -- say one week. Thereafter, if the versions are older than one week, rather than as we do with TTL where we let go of all versions older than TTL, instead, let go of all versions EXCEPT the last one written. So, its like versions==1 when TTL one week. We want to allow that if an error is caught within a week of its happening -- user mistakenly removes a critical table -- then we'll be able to restore up the the moment just before catastrophe hit otherwise, we keep one version only. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-4241: - Issue Type: Bug (was: Sub-task) Parent: (was: HBASE-4071) Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Attachments: 4241.txt As discussed with with Jon, there is room for improvement in how the memstore is flushed to disk. Currently only expired KVs are pruned before flushing, but we can also prune versions if we find at least maxVersions versions in the memstore. The same holds for the new minversion feature: If we find at least minVersion versions in the store we can remove all further versions that are expired. Generally we should use the same mechanism here that is used for Compaction. I.e. StoreScanner. We only need to add a scanner to Memstore that can scan along the current snapshot. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-4241: - Attachment: 4241-v2.txt Better patch. Renames ScannerWrapper to CollectionBackedScanner, also uses correct comparator from Store. (And also changes FIXED_OVERHEAD in Store.java once more as there is a new maxVersions member). Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Attachments: 4241-v2.txt, 4241.txt As discussed with with Jon, there is room for improvement in how the memstore is flushed to disk. Currently only expired KVs are pruned before flushing, but we can also prune versions if we find at least maxVersions versions in the memstore. The same holds for the new minversion feature: If we find at least minVersion versions in the store we can remove all further versions that are expired. Generally we should use the same mechanism here that is used for Compaction. I.e. StoreScanner. We only need to add a scanner to Memstore that can scan along the current snapshot. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4071) Data GC: Remove all versions TTL EXCEPT the last written version
[ https://issues.apache.org/jira/browse/HBASE-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090475#comment-13090475 ] Lars Hofhansl commented on HBASE-4071: -- Still strange that the test passes locally. Data GC: Remove all versions TTL EXCEPT the last written version -- Key: HBASE-4071 URL: https://issues.apache.org/jira/browse/HBASE-4071 Project: HBase Issue Type: New Feature Reporter: stack Assignee: Lars Hofhansl Fix For: 0.92.0 Attachments: MinVersions.diff We were chatting today about our backup cluster. What we want is to be able to restore the dataset from any point of time but only within a limited timeframe -- say one week. Thereafter, if the versions are older than one week, rather than as we do with TTL where we let go of all versions older than TTL, instead, let go of all versions EXCEPT the last one written. So, its like versions==1 when TTL one week. We want to allow that if an error is caught within a week of its happening -- user mistakenly removes a critical table -- then we'll be able to restore up the the moment just before catastrophe hit otherwise, we keep one version only. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-4249) performance.xml - adding network section
performance.xml - adding network section Key: HBASE-4249 URL: https://issues.apache.org/jira/browse/HBASE-4249 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Adding network section in performance.xml Thanks to Nick Seritti from Explorys, who wrote up the source material for this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4249) performance.xml - adding network section
[ https://issues.apache.org/jira/browse/HBASE-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doug Meil updated HBASE-4249: - Attachment: performance_HBASE_4249.xml.patch performance.xml - adding network section Key: HBASE-4249 URL: https://issues.apache.org/jira/browse/HBASE-4249 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Attachments: performance_HBASE_4249.xml.patch Adding network section in performance.xml Thanks to Nick Seritti from Explorys, who wrote up the source material for this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4249) performance.xml - adding network section
[ https://issues.apache.org/jira/browse/HBASE-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doug Meil updated HBASE-4249: - Status: Patch Available (was: Open) performance.xml - adding network section Key: HBASE-4249 URL: https://issues.apache.org/jira/browse/HBASE-4249 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Attachments: performance_HBASE_4249.xml.patch Adding network section in performance.xml Thanks to Nick Seritti from Explorys, who wrote up the source material for this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4249) performance.xml - adding network section
[ https://issues.apache.org/jira/browse/HBASE-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doug Meil updated HBASE-4249: - Resolution: Fixed Status: Resolved (was: Patch Available) performance.xml - adding network section Key: HBASE-4249 URL: https://issues.apache.org/jira/browse/HBASE-4249 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Attachments: performance_HBASE_4249.xml.patch Adding network section in performance.xml Thanks to Nick Seritti from Explorys, who wrote up the source material for this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4250) developer.xml - restructuring, plus adding common patch feedback
[ https://issues.apache.org/jira/browse/HBASE-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doug Meil updated HBASE-4250: - Attachment: developer_HBASE_4250.xml.patch developer.xml - restructuring, plus adding common patch feedback Key: HBASE-4250 URL: https://issues.apache.org/jira/browse/HBASE-4250 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Attachments: developer_HBASE_4250.xml.patch * Did some restructuring of sections * Added section for common patch feedback (based on my own experiences in a recent patch). ** I ran these past Todd JD at this week's hackathon. * mentioning ReviewBoard in patch submission process ** this didn't appear anywhere before. I still need to add more on tips on using it, but this is a start. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-4250) developer.xml - restructuring, plus adding common patch feedback
developer.xml - restructuring, plus adding common patch feedback Key: HBASE-4250 URL: https://issues.apache.org/jira/browse/HBASE-4250 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Attachments: developer_HBASE_4250.xml.patch * Did some restructuring of sections * Added section for common patch feedback (based on my own experiences in a recent patch). ** I ran these past Todd JD at this week's hackathon. * mentioning ReviewBoard in patch submission process ** this didn't appear anywhere before. I still need to add more on tips on using it, but this is a start. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4250) developer.xml - restructuring, plus adding common patch feedback
[ https://issues.apache.org/jira/browse/HBASE-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doug Meil updated HBASE-4250: - Status: Patch Available (was: Open) developer.xml - restructuring, plus adding common patch feedback Key: HBASE-4250 URL: https://issues.apache.org/jira/browse/HBASE-4250 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Attachments: developer_HBASE_4250.xml.patch * Did some restructuring of sections * Added section for common patch feedback (based on my own experiences in a recent patch). ** I ran these past Todd JD at this week's hackathon. * mentioning ReviewBoard in patch submission process ** this didn't appear anywhere before. I still need to add more on tips on using it, but this is a start. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4250) developer.xml - restructuring, plus adding common patch feedback
[ https://issues.apache.org/jira/browse/HBASE-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doug Meil updated HBASE-4250: - Resolution: Fixed Status: Resolved (was: Patch Available) developer.xml - restructuring, plus adding common patch feedback Key: HBASE-4250 URL: https://issues.apache.org/jira/browse/HBASE-4250 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Attachments: developer_HBASE_4250.xml.patch * Did some restructuring of sections * Added section for common patch feedback (based on my own experiences in a recent patch). ** I ran these past Todd JD at this week's hackathon. * mentioning ReviewBoard in patch submission process ** this didn't appear anywhere before. I still need to add more on tips on using it, but this is a start. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[
https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090495#comment-13090495
]
Ted Yu commented on HBASE-4241:
---
Year should be 2011.
{code}
+ * Copyright 2009 The Apache Software Foundation
{code}
I think a better description:
{code}
+ * Utility scanner that can wrap a collection (anything iterable)and pretend to
+ * be a KeyValueScanner.
{code}
would be:
{code}
+ * Utility scanner that wraps a collection (anything iterable) and serves
+ * as a KeyValueScanner.
{code}
Please run through unit tests.
If they pass, please use reviewboard for further comments.
Good work.
Optimize flushing of the Store cache for max versions and (new) min versions
Key: HBASE-4241
URL: https://issues.apache.org/jira/browse/HBASE-4241
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.92.0
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Attachments: 4241-v2.txt, 4241.txt
As discussed with with Jon, there is room for improvement in how the memstore
is flushed to disk.
Currently only expired KVs are pruned before flushing, but we can also prune
versions if we find at least maxVersions versions in the memstore.
The same holds for the new minversion feature: If we find at least minVersion
versions in the store we can remove all further versions that are expired.
Generally we should use the same mechanism here that is used for Compaction.
I.e. StoreScanner. We only need to add a scanner to Memstore that can scan
along the current snapshot.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[
https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090513#comment-13090513
]
Ted Yu commented on HBASE-4241:
---
Since HBASE-4071 was New Feature, this JIRA should be something similar.
Looking at CollectionBackedScanner again, all ctor's (implicitly) take a
comparator. So the description of (anything iterable) is inaccurate.
How about the following:
{code}
+ * Utility scanner that wraps a sortable collection and serves
{code}
Optimize flushing of the Store cache for max versions and (new) min versions
Key: HBASE-4241
URL: https://issues.apache.org/jira/browse/HBASE-4241
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.92.0
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Attachments: 4241-v2.txt, 4241.txt
As discussed with with Jon, there is room for improvement in how the memstore
is flushed to disk.
Currently only expired KVs are pruned before flushing, but we can also prune
versions if we find at least maxVersions versions in the memstore.
The same holds for the new minversion feature: If we find at least minVersion
versions in the store we can remove all further versions that are expired.
Generally we should use the same mechanism here that is used for Compaction.
I.e. StoreScanner. We only need to add a scanner to Memstore that can scan
along the current snapshot.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-4241: - Issue Type: Improvement (was: Bug) Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Attachments: 4241-v2.txt, 4241.txt As discussed with with Jon, there is room for improvement in how the memstore is flushed to disk. Currently only expired KVs are pruned before flushing, but we can also prune versions if we find at least maxVersions versions in the memstore. The same holds for the new minversion feature: If we find at least minVersion versions in the store we can remove all further versions that are expired. Generally we should use the same mechanism here that is used for Compaction. I.e. StoreScanner. We only need to add a scanner to Memstore that can scan along the current snapshot. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090522#comment-13090522 ] Lars Hofhansl commented on HBASE-4241: -- Good point that would make it more clear. I also discovered another problem that broken many of the tests. Fixed now. Once I get a complete test run through without failures I'll file a review-request. Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Attachments: 4241-v2.txt, 4241.txt As discussed with with Jon, there is room for improvement in how the memstore is flushed to disk. Currently only expired KVs are pruned before flushing, but we can also prune versions if we find at least maxVersions versions in the memstore. The same holds for the new minversion feature: If we find at least minVersion versions in the store we can remove all further versions that are expired. Generally we should use the same mechanism here that is used for Compaction. I.e. StoreScanner. We only need to add a scanner to Memstore that can scan along the current snapshot. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4195) Possible inconsistency in a memstore read after a reseek, possible performance improvement
[
https://issues.apache.org/jira/browse/HBASE-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090555#comment-13090555
]
Ted Yu commented on HBASE-4195:
---
+1 on patch (some extra empty lines should be removed).
All tests pass.
Possible inconsistency in a memstore read after a reseek, possible
performance improvement
--
Key: HBASE-4195
URL: https://issues.apache.org/jira/browse/HBASE-4195
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.90.4
Environment: all
Reporter: nkeywal
Assignee: nkeywal
Priority: Critical
Attachments: 20110824_4195_MemStore.patch,
20110824_4195_TestHRegion.patch
This follows the dicussion around HBASE-3855, and the random errors (20%
failure on trunk) on the unit test
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
I saw some points related to numIterReseek, used in the
MemStoreScanner#getNext (line 690):
{noformat}679 protected KeyValue getNext(Iterator it) {
680 KeyValue ret = null;
681 long readPoint = ReadWriteConsistencyControl.getThreadReadPoint();
682 //DebugPrint.println( MS@ + hashCode() + : threadpoint = +
readPoint);
683
684 while (ret == null it.hasNext()) {
685 KeyValue v = it.next();
686 if (v.getMemstoreTS() = readPoint) {
687 // keep it.
688 ret = v;
689 }
690 numIterReseek--;
691 if (numIterReseek == 0) {
692 break;
693}
694 }
695 return ret;
696 }{noformat}
This function is called by seek, reseek, and next. The numIterReseek is only
usefull for reseek.
There are some issues, I am not totally sure it's the root cause of the test
case error, but it could explain partly the randomness of the error, and one
point is for sure a bug.
1) In getNext, numIterReseek is decreased, then compared to zero. The seek
function sets numIterReseek to zero before calling getNext. It means that the
value will be actually negative, hence the test will always fail, and the
loop will continue. It is the expected behaviour, but it's quite smart.
2) In reseek, numIterReseek is not set between the loops on the two
iterators. If the numIterReseek is equals to zero after the loop on the first
one, the loop on the second one will never call seek, as numIterReseek will
be negative.
3) Still in reseek, the test to call seek is (kvsetNextRow == null
numIterReseek == 0). In other words, if kvsetNextRow is not null when
numIterReseek equals zero, numIterReseek will start to be negative at the
next iteration and seek will never be called.
4) You can have side effects if reseek ends with a numIterReseek 0: the
following calls to the next function will decrease numIterReseek to zero,
and getNext will break instead of continuing the loop. As a result, later
calls to next() may return null or not depending on how is configured the
default value for numIterReseek.
To check if the issue comes from point 4, you can set the numIterReseek to
zero before returning in reseek:
{noformat} numIterReseek = 0;
return (kvsetNextRow != null || snapshotNextRow != null);
}{noformat}
On my env, on trunk, it seems to work, but as it's random I am not really
sure. I also had to modify the test (I added a loop) to make it fails more
often, the original test was working quite well here.
It has to be confirmed that this totally fix (it could be partial or
unrelated)
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
before implementing a complete solution.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4195) Possible inconsistency in a memstore read after a reseek, possible performance improvement
[
https://issues.apache.org/jira/browse/HBASE-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-4195:
--
Fix Version/s: 0.90.5
Possible inconsistency in a memstore read after a reseek, possible
performance improvement
--
Key: HBASE-4195
URL: https://issues.apache.org/jira/browse/HBASE-4195
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.90.4
Environment: all
Reporter: nkeywal
Assignee: nkeywal
Priority: Critical
Fix For: 0.90.5
Attachments: 20110824_4195_MemStore.patch,
20110824_4195_TestHRegion.patch
This follows the dicussion around HBASE-3855, and the random errors (20%
failure on trunk) on the unit test
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
I saw some points related to numIterReseek, used in the
MemStoreScanner#getNext (line 690):
{noformat}679 protected KeyValue getNext(Iterator it) {
680 KeyValue ret = null;
681 long readPoint = ReadWriteConsistencyControl.getThreadReadPoint();
682 //DebugPrint.println( MS@ + hashCode() + : threadpoint = +
readPoint);
683
684 while (ret == null it.hasNext()) {
685 KeyValue v = it.next();
686 if (v.getMemstoreTS() = readPoint) {
687 // keep it.
688 ret = v;
689 }
690 numIterReseek--;
691 if (numIterReseek == 0) {
692 break;
693}
694 }
695 return ret;
696 }{noformat}
This function is called by seek, reseek, and next. The numIterReseek is only
usefull for reseek.
There are some issues, I am not totally sure it's the root cause of the test
case error, but it could explain partly the randomness of the error, and one
point is for sure a bug.
1) In getNext, numIterReseek is decreased, then compared to zero. The seek
function sets numIterReseek to zero before calling getNext. It means that the
value will be actually negative, hence the test will always fail, and the
loop will continue. It is the expected behaviour, but it's quite smart.
2) In reseek, numIterReseek is not set between the loops on the two
iterators. If the numIterReseek is equals to zero after the loop on the first
one, the loop on the second one will never call seek, as numIterReseek will
be negative.
3) Still in reseek, the test to call seek is (kvsetNextRow == null
numIterReseek == 0). In other words, if kvsetNextRow is not null when
numIterReseek equals zero, numIterReseek will start to be negative at the
next iteration and seek will never be called.
4) You can have side effects if reseek ends with a numIterReseek 0: the
following calls to the next function will decrease numIterReseek to zero,
and getNext will break instead of continuing the loop. As a result, later
calls to next() may return null or not depending on how is configured the
default value for numIterReseek.
To check if the issue comes from point 4, you can set the numIterReseek to
zero before returning in reseek:
{noformat} numIterReseek = 0;
return (kvsetNextRow != null || snapshotNextRow != null);
}{noformat}
On my env, on trunk, it seems to work, but as it's random I am not really
sure. I also had to modify the test (I added a loop) to make it fails more
often, the original test was working quite well here.
It has to be confirmed that this totally fix (it could be partial or
unrelated)
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
before implementing a complete solution.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4222) Make HLog more resilient to write pipeline failures
[
https://issues.apache.org/jira/browse/HBASE-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Helmling updated HBASE-4222:
-
Attachment: HBASE-4222_trunk_final.patch
Committed patch to trunk following review.
Make HLog more resilient to write pipeline failures
---
Key: HBASE-4222
URL: https://issues.apache.org/jira/browse/HBASE-4222
Project: HBase
Issue Type: Improvement
Components: wal
Reporter: Gary Helmling
Assignee: Gary Helmling
Fix For: 0.92.0
Attachments: HBASE-4222_trunk_final.patch
The current implementation of HLog rolling to recover from transient errors
in the write pipeline seems to have two problems:
# When {{HLog.LogSyncer}} triggers an {{IOException}} during time-based sync
operations, it triggers a log rolling request in the corresponding catch
block, but only after escaping from the internal while loop. As a result,
the {{LogSyncer}} thread will exit and never be restarted from what I can
tell, even if the log rolling was successful.
# Log rolling requests triggered by an {{IOException}} in {{sync()}} or
{{append()}} never happen if no entries have yet been written to the log.
This means that write errors are not immediately recovered, which extends the
exposure to more errors occurring in the pipeline.
In addition, it seems like we should be able to better handle transient
problems, like a rolling restart of DataNodes while the HBase RegionServers
are running. Currently this will reliably cause RegionServer aborts during
log rolling: either an append or time-based sync triggers an initial
{{IOException}}, initiating a log rolling request. However the log rolling
then fails in closing the current writer (All datanodes are bad), causing a
RegionServer abort. In this case, it seems like we should at least allow you
an option to continue with the new writer and only abort on subsequent errors.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4071) Data GC: Remove all versions TTL EXCEPT the last written version
[ https://issues.apache.org/jira/browse/HBASE-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090619#comment-13090619 ] Hudson commented on HBASE-4071: --- Integrated in HBase-TRUNK #2141 (See [https://builds.apache.org/job/HBase-TRUNK/2141/]) HBASE-4071 update FIXED_OVERHEAD for minVersions tedyu : Files : * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java Data GC: Remove all versions TTL EXCEPT the last written version -- Key: HBASE-4071 URL: https://issues.apache.org/jira/browse/HBASE-4071 Project: HBase Issue Type: New Feature Reporter: stack Assignee: Lars Hofhansl Fix For: 0.92.0 Attachments: MinVersions.diff We were chatting today about our backup cluster. What we want is to be able to restore the dataset from any point of time but only within a limited timeframe -- say one week. Thereafter, if the versions are older than one week, rather than as we do with TTL where we let go of all versions older than TTL, instead, let go of all versions EXCEPT the last one written. So, its like versions==1 when TTL one week. We want to allow that if an error is caught within a week of its happening -- user mistakenly removes a critical table -- then we'll be able to restore up the the moment just before catastrophe hit otherwise, we keep one version only. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4222) Make HLog more resilient to write pipeline failures
[
https://issues.apache.org/jira/browse/HBASE-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Helmling updated HBASE-4222:
-
Fix Version/s: (was: 0.92.0)
0.90.5
Adding to 0.90 branch as well
Make HLog more resilient to write pipeline failures
---
Key: HBASE-4222
URL: https://issues.apache.org/jira/browse/HBASE-4222
Project: HBase
Issue Type: Improvement
Components: wal
Reporter: Gary Helmling
Assignee: Gary Helmling
Fix For: 0.90.5
Attachments: HBASE-4222_trunk_final.patch
The current implementation of HLog rolling to recover from transient errors
in the write pipeline seems to have two problems:
# When {{HLog.LogSyncer}} triggers an {{IOException}} during time-based sync
operations, it triggers a log rolling request in the corresponding catch
block, but only after escaping from the internal while loop. As a result,
the {{LogSyncer}} thread will exit and never be restarted from what I can
tell, even if the log rolling was successful.
# Log rolling requests triggered by an {{IOException}} in {{sync()}} or
{{append()}} never happen if no entries have yet been written to the log.
This means that write errors are not immediately recovered, which extends the
exposure to more errors occurring in the pipeline.
In addition, it seems like we should be able to better handle transient
problems, like a rolling restart of DataNodes while the HBase RegionServers
are running. Currently this will reliably cause RegionServer aborts during
log rolling: either an append or time-based sync triggers an initial
{{IOException}}, initiating a log rolling request. However the log rolling
then fails in closing the current writer (All datanodes are bad), causing a
RegionServer abort. In this case, it seems like we should at least allow you
an option to continue with the new writer and only abort on subsequent errors.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4188) Make in-memory table scanning faster, part2 (continuation of hbase-1938)
[ https://issues.apache.org/jira/browse/HBASE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090625#comment-13090625 ] nkeywal commented on HBASE-4188: Yes, I would expect them to be the scenario with consistency between read and flush mentioned in the bug HBASE-4195https://issues.apache.org/jira/browse/HBASE-4195(and already managed in HBASE-2856 https://issues.apache.org/jira/browse/HBASE-2856). You can check this by changing int flushInterval = 10; in the method testWritesWhileGetting, for example by setting it to 2 or 3. This should increase the number of failure. As well, the MemStoreTS of the KV in error will be 0 (it comes from a file). This error (or at least the error I analyzed) comes from the fact that the flush is finished before the end of the Store#next, and not directly to the MemStore. A xarning as well the patch in HBASE-4195https://issues.apache.org/jira/browse/HBASE-4195will conflict with this one, because they both touch the seek reseek function (even if it is actually different parts that are modified). Nothing complex, but I won't be able to do the followup on this until end of next week. Make in-memory table scanning faster, part2 (continuation of hbase-1938) Key: HBASE-4188 URL: https://issues.apache.org/jira/browse/HBASE-4188 Project: HBase Issue Type: Improvement Components: performance Reporter: stack Assignee: nkeywal Priority: Critical Fix For: 0.92.0 Attachments: 4188-mssp.txt This issue is a continuation of hbase-1938 work (That issue is closed). This issue is about getting the last patch posted by nkeywal over in hbase-1938 applied (assigned nkeywal since he's done the work). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4248) Enhancements for Filter Language exposing HBase filters through the Thrift API
[ https://issues.apache.org/jira/browse/HBASE-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090638#comment-13090638 ] Ted Yu commented on HBASE-4248: --- See my comment on HBASE-4176 @ 09/Aug/11 03:45 It would be nice if we can find subclasses of FilterBase dynamically. Enhancements for Filter Language exposing HBase filters through the Thrift API -- Key: HBASE-4248 URL: https://issues.apache.org/jira/browse/HBASE-4248 Project: HBase Issue Type: Improvement Reporter: Anirudh Todi Assignee: Anirudh Todi Priority: Minor Attachments: HBASE-4248(2).patch, HBASE-4248(3).patch, HBASE-4248.patch HBASE-4176 enabled a Filter Language to expose HBase filters to the Thrift API. Here I make a couple of improvements to the that patch: - Enables a show_filters command from the HBase shell that lists the filters from the shell - Moves the creation of the HashMaps into a static block - so that they aren't initialized every time an RPC call is made -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4195) Possible inconsistency in a memstore read after a reseek, possible performance improvement
[
https://issues.apache.org/jira/browse/HBASE-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090641#comment-13090641
]
Ted Yu commented on HBASE-4195:
---
Consecutively run TestHRegion#testWritesWhileGetting 100 times.
All of which passed.
Possible inconsistency in a memstore read after a reseek, possible
performance improvement
--
Key: HBASE-4195
URL: https://issues.apache.org/jira/browse/HBASE-4195
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.90.4
Environment: all
Reporter: nkeywal
Assignee: nkeywal
Priority: Critical
Fix For: 0.90.5
Attachments: 20110824_4195_MemStore.patch,
20110824_4195_TestHRegion.patch
This follows the dicussion around HBASE-3855, and the random errors (20%
failure on trunk) on the unit test
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
I saw some points related to numIterReseek, used in the
MemStoreScanner#getNext (line 690):
{noformat}679 protected KeyValue getNext(Iterator it) {
680 KeyValue ret = null;
681 long readPoint = ReadWriteConsistencyControl.getThreadReadPoint();
682 //DebugPrint.println( MS@ + hashCode() + : threadpoint = +
readPoint);
683
684 while (ret == null it.hasNext()) {
685 KeyValue v = it.next();
686 if (v.getMemstoreTS() = readPoint) {
687 // keep it.
688 ret = v;
689 }
690 numIterReseek--;
691 if (numIterReseek == 0) {
692 break;
693}
694 }
695 return ret;
696 }{noformat}
This function is called by seek, reseek, and next. The numIterReseek is only
usefull for reseek.
There are some issues, I am not totally sure it's the root cause of the test
case error, but it could explain partly the randomness of the error, and one
point is for sure a bug.
1) In getNext, numIterReseek is decreased, then compared to zero. The seek
function sets numIterReseek to zero before calling getNext. It means that the
value will be actually negative, hence the test will always fail, and the
loop will continue. It is the expected behaviour, but it's quite smart.
2) In reseek, numIterReseek is not set between the loops on the two
iterators. If the numIterReseek is equals to zero after the loop on the first
one, the loop on the second one will never call seek, as numIterReseek will
be negative.
3) Still in reseek, the test to call seek is (kvsetNextRow == null
numIterReseek == 0). In other words, if kvsetNextRow is not null when
numIterReseek equals zero, numIterReseek will start to be negative at the
next iteration and seek will never be called.
4) You can have side effects if reseek ends with a numIterReseek 0: the
following calls to the next function will decrease numIterReseek to zero,
and getNext will break instead of continuing the loop. As a result, later
calls to next() may return null or not depending on how is configured the
default value for numIterReseek.
To check if the issue comes from point 4, you can set the numIterReseek to
zero before returning in reseek:
{noformat} numIterReseek = 0;
return (kvsetNextRow != null || snapshotNextRow != null);
}{noformat}
On my env, on trunk, it seems to work, but as it's random I am not really
sure. I also had to modify the test (I added a loop) to make it fails more
often, the original test was working quite well here.
It has to be confirmed that this totally fix (it could be partial or
unrelated)
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileGetting
before implementing a complete solution.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4251) book.xml - adding catalog information in arch section, reorganized schema design, added some extra schema design info
[ https://issues.apache.org/jira/browse/HBASE-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doug Meil updated HBASE-4251: - Attachment: book_HBASE_4251.xml.patch book.xml - adding catalog information in arch section, reorganized schema design, added some extra schema design info - Key: HBASE-4251 URL: https://issues.apache.org/jira/browse/HBASE-4251 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Attachments: book_HBASE_4251.xml.patch * Added catalog section in Architecture (ROOT META description, etc.) * Reorganized all the rowkey design entries into a Rowkey Design section. ** Plus, added a sub-section on reverse-timestamps, since that's a fairly common question on the dist-list. ** added small comment on not having an exceedingly high number of versions unless you really, really want all those values (this also came up on the dist-list) * Moved what was added in HBASE-4242 (minimum versions) as a sub-section of the existing version entry. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-4251) book.xml - adding catalog information in arch section, reorganized schema design, added some extra schema design info
book.xml - adding catalog information in arch section, reorganized schema design, added some extra schema design info - Key: HBASE-4251 URL: https://issues.apache.org/jira/browse/HBASE-4251 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Attachments: book_HBASE_4251.xml.patch * Added catalog section in Architecture (ROOT META description, etc.) * Reorganized all the rowkey design entries into a Rowkey Design section. ** Plus, added a sub-section on reverse-timestamps, since that's a fairly common question on the dist-list. ** added small comment on not having an exceedingly high number of versions unless you really, really want all those values (this also came up on the dist-list) * Moved what was added in HBASE-4242 (minimum versions) as a sub-section of the existing version entry. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4251) book.xml - adding catalog information in arch section, reorganized schema design, added some extra schema design info
[ https://issues.apache.org/jira/browse/HBASE-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doug Meil updated HBASE-4251: - Status: Patch Available (was: Open) book.xml - adding catalog information in arch section, reorganized schema design, added some extra schema design info - Key: HBASE-4251 URL: https://issues.apache.org/jira/browse/HBASE-4251 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Attachments: book_HBASE_4251.xml.patch * Added catalog section in Architecture (ROOT META description, etc.) * Reorganized all the rowkey design entries into a Rowkey Design section. ** Plus, added a sub-section on reverse-timestamps, since that's a fairly common question on the dist-list. ** added small comment on not having an exceedingly high number of versions unless you really, really want all those values (this also came up on the dist-list) * Moved what was added in HBASE-4242 (minimum versions) as a sub-section of the existing version entry. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4251) book.xml - adding catalog information in arch section, reorganized schema design, added some extra schema design info
[ https://issues.apache.org/jira/browse/HBASE-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doug Meil updated HBASE-4251: - Resolution: Fixed Status: Resolved (was: Patch Available) book.xml - adding catalog information in arch section, reorganized schema design, added some extra schema design info - Key: HBASE-4251 URL: https://issues.apache.org/jira/browse/HBASE-4251 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Attachments: book_HBASE_4251.xml.patch * Added catalog section in Architecture (ROOT META description, etc.) * Reorganized all the rowkey design entries into a Rowkey Design section. ** Plus, added a sub-section on reverse-timestamps, since that's a fairly common question on the dist-list. ** added small comment on not having an exceedingly high number of versions unless you really, really want all those values (this also came up on the dist-list) * Moved what was added in HBASE-4242 (minimum versions) as a sub-section of the existing version entry. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090670#comment-13090670 ] jirapos...@reviews.apache.org commented on HBASE-4241: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1650/ --- Review request for hbase, Ted Yu, Michael Stack, and Jonathan Gray. Summary --- This avoids flushing row versions to disk that are known to be GC'd by the next compaction anyway. This covers two scenarios: 1. maxVersions=N and we find at least N versions in the memstore. We can safely avoid flushing any further versions to disk. 2. similarly minVersions=N and we find at least N versions in the memstore. Now we can safely avoid flushing any further *expired* versions to disk. This changes the Store flush to use the same mechanism that used for compactions. I borrowed some code from the tests and refactored the test code to use a new utility class that wraps a sorted collection and then behaves like KeyValueScanner. The same class is used to create scanner over the memstore's snapshot. This addresses bug HBASE-4241. https://issues.apache.org/jira/browse/HBASE-4241 Diffs - http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 1161347 http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/util/CollectionBackedScanner.java PRE-CREATION http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/KeyValueScanFixture.java 1161347 http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestKeyValueHeap.java 1161347 http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestKeyValueScanFixture.java 1161347 http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestMinVersions.java 1161347 http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java 1161347 Diff: https://reviews.apache.org/r/1650/diff Testing --- Ran all tests. TestHTablePool and TestDistributedLogSplitting error out (with or without my change). I had to change three tests that incorrectly relied on old rows hanging around after a flush (or were otherwise incorrect). No new test, as this should cause no functional change. Thanks, Lars Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Attachments: 4241-v2.txt, 4241.txt As discussed with with Jon, there is room for improvement in how the memstore is flushed to disk. Currently only expired KVs are pruned before flushing, but we can also prune versions if we find at least maxVersions versions in the memstore. The same holds for the new minversion feature: If we find at least minVersion versions in the store we can remove all further versions that are expired. Generally we should use the same mechanism here that is used for Compaction. I.e. StoreScanner. We only need to add a scanner to Memstore that can scan along the current snapshot. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4250) developer.xml - restructuring, plus adding common patch feedback
[ https://issues.apache.org/jira/browse/HBASE-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090675#comment-13090675 ] Hudson commented on HBASE-4250: --- Integrated in HBase-TRUNK #2142 (See [https://builds.apache.org/job/HBase-TRUNK/2142/]) HBASE-4250 developer.xml dmeil : Files : * /hbase/trunk/src/docbkx/developer.xml developer.xml - restructuring, plus adding common patch feedback Key: HBASE-4250 URL: https://issues.apache.org/jira/browse/HBASE-4250 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Attachments: developer_HBASE_4250.xml.patch * Did some restructuring of sections * Added section for common patch feedback (based on my own experiences in a recent patch). ** I ran these past Todd JD at this week's hackathon. * mentioning ReviewBoard in patch submission process ** this didn't appear anywhere before. I still need to add more on tips on using it, but this is a start. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4222) Make HLog more resilient to write pipeline failures
[
https://issues.apache.org/jira/browse/HBASE-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090674#comment-13090674
]
Hudson commented on HBASE-4222:
---
Integrated in HBase-TRUNK #2142 (See
[https://builds.apache.org/job/HBase-TRUNK/2142/])
HBASE-4222 Allow HLog to retry log roll on transient write pipeline errors
garyh :
Files :
* /hbase/trunk/src/main/resources/hbase-default.xml
* /hbase/trunk/CHANGES.txt
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLog.java
*
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestLogRolling.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/LogRoller.java
Make HLog more resilient to write pipeline failures
---
Key: HBASE-4222
URL: https://issues.apache.org/jira/browse/HBASE-4222
Project: HBase
Issue Type: Improvement
Components: wal
Reporter: Gary Helmling
Assignee: Gary Helmling
Fix For: 0.90.5
Attachments: HBASE-4222_trunk_final.patch
The current implementation of HLog rolling to recover from transient errors
in the write pipeline seems to have two problems:
# When {{HLog.LogSyncer}} triggers an {{IOException}} during time-based sync
operations, it triggers a log rolling request in the corresponding catch
block, but only after escaping from the internal while loop. As a result,
the {{LogSyncer}} thread will exit and never be restarted from what I can
tell, even if the log rolling was successful.
# Log rolling requests triggered by an {{IOException}} in {{sync()}} or
{{append()}} never happen if no entries have yet been written to the log.
This means that write errors are not immediately recovered, which extends the
exposure to more errors occurring in the pipeline.
In addition, it seems like we should be able to better handle transient
problems, like a rolling restart of DataNodes while the HBase RegionServers
are running. Currently this will reliably cause RegionServer aborts during
log rolling: either an append or time-based sync triggers an initial
{{IOException}}, initiating a log rolling request. However the log rolling
then fails in closing the current writer (All datanodes are bad), causing a
RegionServer abort. In this case, it seems like we should at least allow you
an option to continue with the new writer and only abort on subsequent errors.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4249) performance.xml - adding network section
[ https://issues.apache.org/jira/browse/HBASE-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090673#comment-13090673 ] Hudson commented on HBASE-4249: --- Integrated in HBase-TRUNK #2142 (See [https://builds.apache.org/job/HBase-TRUNK/2142/]) HBASE-4249 - performance.xml (adding network section) dmeil : Files : * /hbase/trunk/src/docbkx/performance.xml performance.xml - adding network section Key: HBASE-4249 URL: https://issues.apache.org/jira/browse/HBASE-4249 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Attachments: performance_HBASE_4249.xml.patch Adding network section in performance.xml Thanks to Nick Seritti from Explorys, who wrote up the source material for this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090676#comment-13090676 ] Lars Hofhansl commented on HBASE-4241: -- I have an (unrealistic) local test scenario that basically updates the same row in a state table. VERSIONS is set to 1. In this scenario 1m updates produced 50mb of garbage that is completely avoided with this change. Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Attachments: 4241-v2.txt, 4241.txt As discussed with with Jon, there is room for improvement in how the memstore is flushed to disk. Currently only expired KVs are pruned before flushing, but we can also prune versions if we find at least maxVersions versions in the memstore. The same holds for the new minversion feature: If we find at least minVersion versions in the store we can remove all further versions that are expired. Generally we should use the same mechanism here that is used for Compaction. I.e. StoreScanner. We only need to add a scanner to Memstore that can scan along the current snapshot. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4124) ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'.
[ https://issues.apache.org/jira/browse/HBASE-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090677#comment-13090677 ] gaojinchao commented on HBASE-4124: --- @Ted I have run all the tests. Thanks for your work. ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'. Key: HBASE-4124 URL: https://issues.apache.org/jira/browse/HBASE-4124 Project: HBase Issue Type: Bug Components: master Reporter: fulin wang Assignee: gaojinchao Fix For: 0.90.5 Attachments: HBASE-4124_Branch90V1_trial.patch, HBASE-4124_Branch90V2.patch, HBASE-4124_Branch90V3.patch, log.txt Original Estimate: 0.4h Remaining Estimate: 0.4h ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'. Issue: The RS failed besause of 'already online on this server' and return; The HM can not receive the message and report 'Regions in transition timed out'. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-4252) TestLogRolling's low-probability failure
TestLogRolling's low-probability failure
-
Key: HBASE-4252
URL: https://issues.apache.org/jira/browse/HBASE-4252
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.90.4
Reporter: Jieshan Bean
Assignee: Jieshan Bean
Fix For: 0.90.5
Before I explain why it could happen, I describe how does this
test(testLogRollOnDatanodeDeath) works:
1. There's two datanodes A B in env. So the log has two replications first
which is the expect and default value.
2. Add a new datanode C and wait it active.
3. Kill A who is in the pipelines.
4. Write data. So trigger a new rollWriter while the next sync. And it only
happens once. For the new log has two replications.
5. Kill another datanode B.
6. Write batch data to trigger consecutive rollWriter. So LowReplication-Roller
will be disabled.
7. Add a new datanode D and wait it active.
8. Send a rollWriter request. So expect the new log will has the default
replications.
9. Write batch data. Assert the LogReplication-Roller will be enabled.
Maybe the rollWriter request in step 8 can't be executed affected by the
previous roll requests from step 6. So the current log replication is not the
expect value.
{noformat}
public byte [][] rollWriter() throws FailedLogCloseException, IOException {
// Return if nothing to flush.
if (this.writer != null this.numEntries.get() = 0) {
return null;
}
{noformat}
So the following assertion must be safeguarded.
{noformat}
log.rollWriter();
batchWriteAndWait(table, 14, true, 1);
assertTrue(LowReplication Roller should've been enabled,
log.isLowReplicationRollEnabled());
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4124) ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'.
[ https://issues.apache.org/jira/browse/HBASE-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090698#comment-13090698 ] gaojinchao commented on HBASE-4124: --- @ram How come we have a dead RS if we dont kill the RS gao: If you stop the cluster, The meta will handle the server information. if the master is also killed how can the regions be assigned to some other RS gao: When master startup, it collects the regions on a same region server and call sendRegionOpen(destination, regions). If the region is relatively large number, when region server opens the reigons needs a long time. when master crash, the new master may reopen the regions on another region server. ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'. Key: HBASE-4124 URL: https://issues.apache.org/jira/browse/HBASE-4124 Project: HBase Issue Type: Bug Components: master Reporter: fulin wang Assignee: gaojinchao Fix For: 0.90.5 Attachments: HBASE-4124_Branch90V1_trial.patch, HBASE-4124_Branch90V2.patch, HBASE-4124_Branch90V3.patch, log.txt Original Estimate: 0.4h Remaining Estimate: 0.4h ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'. Issue: The RS failed besause of 'already online on this server' and return; The HM can not receive the message and report 'Regions in transition timed out'. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-3845) data loss because lastSeqWritten can miss memstore edits
[ https://issues.apache.org/jira/browse/HBASE-3845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gaojinchao updated HBASE-3845: -- Attachment: HBASE-3845_branch90V1.patch data loss because lastSeqWritten can miss memstore edits Key: HBASE-3845 URL: https://issues.apache.org/jira/browse/HBASE-3845 Project: HBase Issue Type: Bug Affects Versions: 0.90.3 Reporter: Prakash Khemani Assignee: ramkrishna.s.vasudevan Priority: Critical Fix For: 0.92.0 Attachments: 0001-HBASE-3845-data-loss-because-lastSeqWritten-can-miss.patch, HBASE-3845-fix-TestResettingCounters-test.txt, HBASE-3845_1.patch, HBASE-3845_2.patch, HBASE-3845_4.patch, HBASE-3845_5.patch, HBASE-3845_6.patch, HBASE-3845__trunk.patch, HBASE-3845_branch90V1.patch, HBASE-3845_trunk_2.patch, HBASE-3845_trunk_3.patch (I don't have a test case to prove this yet but I have run it by Dhruba and Kannan internally and wanted to put this up for some feedback.) In this discussion let us assume that the region has only one column family. That way I can use region/memstore interchangeably. After a memstore flush it is possible for lastSeqWritten to have a log-sequence-id for a region that is not the earliest log-sequence-id for that region's memstore. HLog.append() does a putIfAbsent into lastSequenceWritten. This is to ensure that we only keep track of the earliest log-sequence-number that is present in the memstore. Every time the memstore is flushed we remove the region's entry in lastSequenceWritten and wait for the next append to populate this entry again. This is where the problem happens. step 1: flusher.prepare() snapshots the memstore under HRegion.updatesLock.writeLock(). step 2 : as soon as the updatesLock.writeLock() is released new entries will be added into the memstore. step 3 : wal.completeCacheFlush() is called. This method removes the region's entry from lastSeqWritten. step 4: the next append will create a new entry for the region in lastSeqWritten(). But this will be the log seq id of the current append. All the edits that were added in step 2 are missing. == as a temporary measure, instead of removing the region's entry in step 3 I will replace it with the log-seq-id of the region-flush-event. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4222) Make HLog more resilient to write pipeline failures
[
https://issues.apache.org/jira/browse/HBASE-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Helmling updated HBASE-4222:
-
Attachment: HBASE-4222_0.90.patch
Patch committed to 0.90 branch
Make HLog more resilient to write pipeline failures
---
Key: HBASE-4222
URL: https://issues.apache.org/jira/browse/HBASE-4222
Project: HBase
Issue Type: Improvement
Components: wal
Reporter: Gary Helmling
Assignee: Gary Helmling
Fix For: 0.90.5
Attachments: HBASE-4222_0.90.patch, HBASE-4222_trunk_final.patch
The current implementation of HLog rolling to recover from transient errors
in the write pipeline seems to have two problems:
# When {{HLog.LogSyncer}} triggers an {{IOException}} during time-based sync
operations, it triggers a log rolling request in the corresponding catch
block, but only after escaping from the internal while loop. As a result,
the {{LogSyncer}} thread will exit and never be restarted from what I can
tell, even if the log rolling was successful.
# Log rolling requests triggered by an {{IOException}} in {{sync()}} or
{{append()}} never happen if no entries have yet been written to the log.
This means that write errors are not immediately recovered, which extends the
exposure to more errors occurring in the pipeline.
In addition, it seems like we should be able to better handle transient
problems, like a rolling restart of DataNodes while the HBase RegionServers
are running. Currently this will reliably cause RegionServer aborts during
log rolling: either an append or time-based sync triggers an initial
{{IOException}}, initiating a log rolling request. However the log rolling
then fails in closing the current writer (All datanodes are bad), causing a
RegionServer abort. In this case, it seems like we should at least allow you
an option to continue with the new writer and only abort on subsequent errors.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4248) Enhancements for Filter Language exposing HBase filters through the Thrift API
[ https://issues.apache.org/jira/browse/HBASE-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090741#comment-13090741 ] stack commented on HBASE-4248: -- Yeah Ted, I had same comment on finding filters dynamically but I do not know how to do a listing of all in a CLASSPATH that implement a particular Interface (Do you?). @Anirudh I'll +1 this if the list of filters -- filterHashMap.put, etc. -- is not duplicated elsewhere. I have my suspicions (e.g. there is a list mentioned in the comment here -- https://issues.apache.org/jira/browse/HBASE-4176?focusedCommentId=13081400page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13081400 -- but I am not able to find this list in the final patch for hbase-4176 so it probably didn't go in?) I think this addition a nice addition to 4176. Enhancements for Filter Language exposing HBase filters through the Thrift API -- Key: HBASE-4248 URL: https://issues.apache.org/jira/browse/HBASE-4248 Project: HBase Issue Type: Improvement Reporter: Anirudh Todi Assignee: Anirudh Todi Priority: Minor Attachments: HBASE-4248(2).patch, HBASE-4248(3).patch, HBASE-4248.patch HBASE-4176 enabled a Filter Language to expose HBase filters to the Thrift API. Here I make a couple of improvements to the that patch: - Enables a show_filters command from the HBase shell that lists the filters from the shell - Moves the creation of the HashMaps into a static block - so that they aren't initialized every time an RPC call is made -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3845) data loss because lastSeqWritten can miss memstore edits
[ https://issues.apache.org/jira/browse/HBASE-3845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090740#comment-13090740 ] gaojinchao commented on HBASE-3845: --- @RAM I have run all the unit tests, Please help to review it firstly. Thanks. I will construct the scene to verify today. data loss because lastSeqWritten can miss memstore edits Key: HBASE-3845 URL: https://issues.apache.org/jira/browse/HBASE-3845 Project: HBase Issue Type: Bug Affects Versions: 0.90.3 Reporter: Prakash Khemani Assignee: ramkrishna.s.vasudevan Priority: Critical Fix For: 0.92.0 Attachments: 0001-HBASE-3845-data-loss-because-lastSeqWritten-can-miss.patch, HBASE-3845-fix-TestResettingCounters-test.txt, HBASE-3845_1.patch, HBASE-3845_2.patch, HBASE-3845_4.patch, HBASE-3845_5.patch, HBASE-3845_6.patch, HBASE-3845__trunk.patch, HBASE-3845_branch90V1.patch, HBASE-3845_trunk_2.patch, HBASE-3845_trunk_3.patch (I don't have a test case to prove this yet but I have run it by Dhruba and Kannan internally and wanted to put this up for some feedback.) In this discussion let us assume that the region has only one column family. That way I can use region/memstore interchangeably. After a memstore flush it is possible for lastSeqWritten to have a log-sequence-id for a region that is not the earliest log-sequence-id for that region's memstore. HLog.append() does a putIfAbsent into lastSequenceWritten. This is to ensure that we only keep track of the earliest log-sequence-number that is present in the memstore. Every time the memstore is flushed we remove the region's entry in lastSequenceWritten and wait for the next append to populate this entry again. This is where the problem happens. step 1: flusher.prepare() snapshots the memstore under HRegion.updatesLock.writeLock(). step 2 : as soon as the updatesLock.writeLock() is released new entries will be added into the memstore. step 3 : wal.completeCacheFlush() is called. This method removes the region's entry from lastSeqWritten. step 4: the next append will create a new entry for the region in lastSeqWritten(). But this will be the log seq id of the current append. All the edits that were added in step 2 are missing. == as a temporary measure, instead of removing the region's entry in step 3 I will replace it with the log-seq-id of the region-flush-event. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-4222) Make HLog more resilient to write pipeline failures
[
https://issues.apache.org/jira/browse/HBASE-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Helmling resolved HBASE-4222.
--
Resolution: Fixed
Committed to 0.90 branch and trunk.
Make HLog more resilient to write pipeline failures
---
Key: HBASE-4222
URL: https://issues.apache.org/jira/browse/HBASE-4222
Project: HBase
Issue Type: Improvement
Components: wal
Reporter: Gary Helmling
Assignee: Gary Helmling
Fix For: 0.90.5
Attachments: HBASE-4222_0.90.patch, HBASE-4222_trunk_final.patch
The current implementation of HLog rolling to recover from transient errors
in the write pipeline seems to have two problems:
# When {{HLog.LogSyncer}} triggers an {{IOException}} during time-based sync
operations, it triggers a log rolling request in the corresponding catch
block, but only after escaping from the internal while loop. As a result,
the {{LogSyncer}} thread will exit and never be restarted from what I can
tell, even if the log rolling was successful.
# Log rolling requests triggered by an {{IOException}} in {{sync()}} or
{{append()}} never happen if no entries have yet been written to the log.
This means that write errors are not immediately recovered, which extends the
exposure to more errors occurring in the pipeline.
In addition, it seems like we should be able to better handle transient
problems, like a rolling restart of DataNodes while the HBase RegionServers
are running. Currently this will reliably cause RegionServer aborts during
log rolling: either an append or time-based sync triggers an initial
{{IOException}}, initiating a log rolling request. However the log rolling
then fails in closing the current writer (All datanodes are bad), causing a
RegionServer abort. In this case, it seems like we should at least allow you
an option to continue with the new writer and only abort on subsequent errors.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4124) ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'.
[ https://issues.apache.org/jira/browse/HBASE-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090752#comment-13090752 ] Ted Yu commented on HBASE-4124: --- +1 on patch version 3. ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'. Key: HBASE-4124 URL: https://issues.apache.org/jira/browse/HBASE-4124 Project: HBase Issue Type: Bug Components: master Reporter: fulin wang Assignee: gaojinchao Fix For: 0.90.5 Attachments: HBASE-4124_Branch90V1_trial.patch, HBASE-4124_Branch90V2.patch, HBASE-4124_Branch90V3.patch, log.txt Original Estimate: 0.4h Remaining Estimate: 0.4h ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'. Issue: The RS failed besause of 'already online on this server' and return; The HM can not receive the message and report 'Regions in transition timed out'. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3845) data loss because lastSeqWritten can miss memstore edits
[
https://issues.apache.org/jira/browse/HBASE-3845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090756#comment-13090756
]
ramkrishna.s.vasudevan commented on HBASE-3845:
---
{code}
+ if (wal != null)
+wal.abortCacheFlush(this.regionInfo.getEncodedNameAsBytes());
{code}
Pls uses braces as there is a second line.
data loss because lastSeqWritten can miss memstore edits
Key: HBASE-3845
URL: https://issues.apache.org/jira/browse/HBASE-3845
Project: HBase
Issue Type: Bug
Affects Versions: 0.90.3
Reporter: Prakash Khemani
Assignee: ramkrishna.s.vasudevan
Priority: Critical
Fix For: 0.92.0
Attachments:
0001-HBASE-3845-data-loss-because-lastSeqWritten-can-miss.patch,
HBASE-3845-fix-TestResettingCounters-test.txt, HBASE-3845_1.patch,
HBASE-3845_2.patch, HBASE-3845_4.patch, HBASE-3845_5.patch,
HBASE-3845_6.patch, HBASE-3845__trunk.patch, HBASE-3845_branch90V1.patch,
HBASE-3845_trunk_2.patch, HBASE-3845_trunk_3.patch
(I don't have a test case to prove this yet but I have run it by Dhruba and
Kannan internally and wanted to put this up for some feedback.)
In this discussion let us assume that the region has only one column family.
That way I can use region/memstore interchangeably.
After a memstore flush it is possible for lastSeqWritten to have a
log-sequence-id for a region that is not the earliest log-sequence-id for
that region's memstore.
HLog.append() does a putIfAbsent into lastSequenceWritten. This is to ensure
that we only keep track of the earliest log-sequence-number that is present
in the memstore.
Every time the memstore is flushed we remove the region's entry in
lastSequenceWritten and wait for the next append to populate this entry
again. This is where the problem happens.
step 1:
flusher.prepare() snapshots the memstore under
HRegion.updatesLock.writeLock().
step 2 :
as soon as the updatesLock.writeLock() is released new entries will be added
into the memstore.
step 3 :
wal.completeCacheFlush() is called. This method removes the region's entry
from lastSeqWritten.
step 4:
the next append will create a new entry for the region in lastSeqWritten().
But this will be the log seq id of the current append. All the edits that
were added in step 2 are missing.
==
as a temporary measure, instead of removing the region's entry in step 3 I
will replace it with the log-seq-id of the region-flush-event.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4124) ZK restarted while assigning a region, new active HM re-assign it but the RS warned 'already online on this server'.
[
https://issues.apache.org/jira/browse/HBASE-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090759#comment-13090759
]
ramkrishna.s.vasudevan commented on HBASE-4124:
---
{bq}.sorry.step 3: startup master again .
This statement confused me a bit.
Thanks for your explanation. :)
ZK restarted while assigning a region, new active HM re-assign it but the RS
warned 'already online on this server'.
Key: HBASE-4124
URL: https://issues.apache.org/jira/browse/HBASE-4124
Project: HBase
Issue Type: Bug
Components: master
Reporter: fulin wang
Assignee: gaojinchao
Fix For: 0.90.5
Attachments: HBASE-4124_Branch90V1_trial.patch,
HBASE-4124_Branch90V2.patch, HBASE-4124_Branch90V3.patch, log.txt
Original Estimate: 0.4h
Remaining Estimate: 0.4h
ZK restarted while assigning a region, new active HM re-assign it but the RS
warned 'already online on this server'.
Issue:
The RS failed besause of 'already online on this server' and return; The HM
can not receive the message and report 'Regions in transition timed out'.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4188) Make in-memory table scanning faster, part2 (continuation of hbase-1938)
[ https://issues.apache.org/jira/browse/HBASE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090758#comment-13090758 ] stack commented on HBASE-4188: -- I changed the int flushInterval to 3 and now I get no failures. Trying 5. Make in-memory table scanning faster, part2 (continuation of hbase-1938) Key: HBASE-4188 URL: https://issues.apache.org/jira/browse/HBASE-4188 Project: HBase Issue Type: Improvement Components: performance Reporter: stack Assignee: nkeywal Priority: Critical Fix For: 0.92.0 Attachments: 4188-mssp.txt This issue is a continuation of hbase-1938 work (That issue is closed). This issue is about getting the last patch posted by nkeywal over in hbase-1938 applied (assigned nkeywal since he's done the work). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090761#comment-13090761 ] jirapos...@reviews.apache.org commented on HBASE-4241: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1650/#review1625 --- Nice work. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java https://reviews.apache.org/r/1650/#comment3654 Line wrap is needed for this long line. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java https://reviews.apache.org/r/1650/#comment3655 This should be false. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/util/CollectionBackedScanner.java https://reviews.apache.org/r/1650/#comment3656 Minor comment: This ctor is used by KeyValueScanFixture below. Putting comparator as first parameter would make it more readable. - Ted On 2011-08-25 01:28:34, Lars Hofhansl wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/1650/ bq. --- bq. bq. (Updated 2011-08-25 01:28:34) bq. bq. bq. Review request for hbase, Ted Yu, Michael Stack, and Jonathan Gray. bq. bq. bq. Summary bq. --- bq. bq. This avoids flushing row versions to disk that are known to be GC'd by the next compaction anyway. bq. This covers two scenarios: bq. 1. maxVersions=N and we find at least N versions in the memstore. We can safely avoid flushing any further versions to disk. bq. 2. similarly minVersions=N and we find at least N versions in the memstore. Now we can safely avoid flushing any further *expired* versions to disk. bq. bq. This changes the Store flush to use the same mechanism that used for compactions. bq. I borrowed some code from the tests and refactored the test code to use a new utility class that wraps a sorted collection and then behaves like KeyValueScanner. The same class is used to create scanner over the memstore's snapshot. bq. bq. bq. This addresses bug HBASE-4241. bq. https://issues.apache.org/jira/browse/HBASE-4241 bq. bq. bq. Diffs bq. - bq. bq. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/util/CollectionBackedScanner.java PRE-CREATION bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/KeyValueScanFixture.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestKeyValueHeap.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestKeyValueScanFixture.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestMinVersions.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java 1161347 bq. bq. Diff: https://reviews.apache.org/r/1650/diff bq. bq. bq. Testing bq. --- bq. bq. Ran all tests. TestHTablePool and TestDistributedLogSplitting error out (with or without my change). bq. I had to change three tests that incorrectly relied on old rows hanging around after a flush (or were otherwise incorrect). bq. bq. No new test, as this should cause no functional change. bq. bq. bq. Thanks, bq. bq. Lars bq. bq. Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Attachments: 4241-v2.txt, 4241.txt As discussed with with Jon, there is room for improvement in how the memstore is flushed to disk. Currently only expired KVs are pruned before flushing, but we can also prune versions if we find at least maxVersions versions in the memstore. The same holds for the new minversion feature: If we find at least minVersion versions in the store we can remove all further versions that are expired. Generally we should use the same mechanism here that is used for Compaction. I.e. StoreScanner. We only
[jira] [Commented] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090765#comment-13090765 ] jirapos...@reviews.apache.org commented on HBASE-4241: -- bq. On 2011-08-25 04:29:19, Ted Yu wrote: bq. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java, line 490 bq. https://reviews.apache.org/r/1650/diff/2/?file=35429#file35429line490 bq. bq. Line wrap is needed for this long line. Will do. bq. On 2011-08-25 04:29:19, Ted Yu wrote: bq. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java, line 491 bq. https://reviews.apache.org/r/1650/diff/2/?file=35429#file35429line491 bq. bq. This should be false. This definitely needs to be true. Deletes need to be retained when the cache is flushed. True, means to retain deletes. (I had this the wrong way in my first attempt as well and then wondered why all the deleted rows were not removed) bq. On 2011-08-25 04:29:19, Ted Yu wrote: bq. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/util/CollectionBackedScanner.java, line 64 bq. https://reviews.apache.org/r/1650/diff/2/?file=35430#file35430line64 bq. bq. Minor comment: bq. This ctor is used by KeyValueScanFixture below. Putting comparator as first parameter would make it more readable. Agreed, I'll change the order. - Lars --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1650/#review1625 --- On 2011-08-25 01:28:34, Lars Hofhansl wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/1650/ bq. --- bq. bq. (Updated 2011-08-25 01:28:34) bq. bq. bq. Review request for hbase, Ted Yu, Michael Stack, and Jonathan Gray. bq. bq. bq. Summary bq. --- bq. bq. This avoids flushing row versions to disk that are known to be GC'd by the next compaction anyway. bq. This covers two scenarios: bq. 1. maxVersions=N and we find at least N versions in the memstore. We can safely avoid flushing any further versions to disk. bq. 2. similarly minVersions=N and we find at least N versions in the memstore. Now we can safely avoid flushing any further *expired* versions to disk. bq. bq. This changes the Store flush to use the same mechanism that used for compactions. bq. I borrowed some code from the tests and refactored the test code to use a new utility class that wraps a sorted collection and then behaves like KeyValueScanner. The same class is used to create scanner over the memstore's snapshot. bq. bq. bq. This addresses bug HBASE-4241. bq. https://issues.apache.org/jira/browse/HBASE-4241 bq. bq. bq. Diffs bq. - bq. bq. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/util/CollectionBackedScanner.java PRE-CREATION bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/KeyValueScanFixture.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestKeyValueHeap.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestKeyValueScanFixture.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestMinVersions.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java 1161347 bq. bq. Diff: https://reviews.apache.org/r/1650/diff bq. bq. bq. Testing bq. --- bq. bq. Ran all tests. TestHTablePool and TestDistributedLogSplitting error out (with or without my change). bq. I had to change three tests that incorrectly relied on old rows hanging around after a flush (or were otherwise incorrect). bq. bq. No new test, as this should cause no functional change. bq. bq. bq. Thanks, bq. bq. Lars bq. bq. Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl
[jira] [Commented] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090767#comment-13090767 ] jirapos...@reviews.apache.org commented on HBASE-4241: -- bq. On 2011-08-25 04:29:19, Ted Yu wrote: bq. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/util/CollectionBackedScanner.java, line 64 bq. https://reviews.apache.org/r/1650/diff/2/?file=35430#file35430line64 bq. bq. Minor comment: bq. This ctor is used by KeyValueScanFixture below. Putting comparator as first parameter would make it more readable. bq. bq. Lars Hofhansl wrote: bq. Agreed, I'll change the order. Actually all the other constructors take the comparator as the 2nd argument. I think I either change them all or leave them all in this order. - Lars --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1650/#review1625 --- On 2011-08-25 01:28:34, Lars Hofhansl wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/1650/ bq. --- bq. bq. (Updated 2011-08-25 01:28:34) bq. bq. bq. Review request for hbase, Ted Yu, Michael Stack, and Jonathan Gray. bq. bq. bq. Summary bq. --- bq. bq. This avoids flushing row versions to disk that are known to be GC'd by the next compaction anyway. bq. This covers two scenarios: bq. 1. maxVersions=N and we find at least N versions in the memstore. We can safely avoid flushing any further versions to disk. bq. 2. similarly minVersions=N and we find at least N versions in the memstore. Now we can safely avoid flushing any further *expired* versions to disk. bq. bq. This changes the Store flush to use the same mechanism that used for compactions. bq. I borrowed some code from the tests and refactored the test code to use a new utility class that wraps a sorted collection and then behaves like KeyValueScanner. The same class is used to create scanner over the memstore's snapshot. bq. bq. bq. This addresses bug HBASE-4241. bq. https://issues.apache.org/jira/browse/HBASE-4241 bq. bq. bq. Diffs bq. - bq. bq. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/util/CollectionBackedScanner.java PRE-CREATION bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/KeyValueScanFixture.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestKeyValueHeap.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestKeyValueScanFixture.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestMinVersions.java 1161347 bq. http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java 1161347 bq. bq. Diff: https://reviews.apache.org/r/1650/diff bq. bq. bq. Testing bq. --- bq. bq. Ran all tests. TestHTablePool and TestDistributedLogSplitting error out (with or without my change). bq. I had to change three tests that incorrectly relied on old rows hanging around after a flush (or were otherwise incorrect). bq. bq. No new test, as this should cause no functional change. bq. bq. bq. Thanks, bq. bq. Lars bq. bq. Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Attachments: 4241-v2.txt, 4241.txt As discussed with with Jon, there is room for improvement in how the memstore is flushed to disk. Currently only expired KVs are pruned before flushing, but we can also prune versions if we find at least maxVersions versions in the memstore. The same holds for the new minversion feature: If we find at least minVersion versions in the store we can remove all further versions that are expired. Generally we should use the same mechanism here that is used for Compaction. I.e. StoreScanner. We only need to add a scanner to Memstore that can scan along the current
[jira] [Commented] (HBASE-4217) HRS.closeRegion should be able to close regions with only the encoded name
[ https://issues.apache.org/jira/browse/HBASE-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090769#comment-13090769 ] stack commented on HBASE-4217: -- I wrote the below to go against your first comment but your second comment seems to address the below so ignore it (I'm posting it in case the below has not been addressed). I'm going to look at the patch not. Good on you Ram. bq. The new api is not using the encoded region name. This issue is about doing a closeRegion with the encoded name. The HREgionServer has a Map of regions keyed by the encoded name of the region. Its needed for the case described at the head of this issue where we don't have the region name to hand, all we have is the encoded name. The MetaReader.getRegion is not needed if you have the ServerName and the encoded name? You'd use the ServerName to figure the connection to the HRI, then you would invoke closeRegion (In the guts of closeRegion, it could figure it was an encoded name only or if it was a full region name just be looking at what it was passed -- so perhaps you don't even need to add a new method to HRegionInterface, etc., just add a check to the head of the current closeRegion method? HRS.closeRegion should be able to close regions with only the encoded name -- Key: HBASE-4217 URL: https://issues.apache.org/jira/browse/HBASE-4217 Project: HBase Issue Type: Improvement Affects Versions: 0.90.4 Reporter: Jean-Daniel Cryans Assignee: ramkrishna.s.vasudevan Fix For: 0.92.0 Attachments: HBASE-4217.patch, HBASE-4217_1.patch, HBASE-4217_2.patch We had some sort of an outage this morning due to a few racks losing power, and some regions were left in the following state: ERROR: Region UNKNOWN_REGION on sv4r17s9:60020, key=e32bbe1f48c9b3633c557dc0291b90a3, not on HDFS or in META but deployed on sv4r17s9:60020 That region was deleted by the master but the region server never got the memo. Right now there's no way to force close it because HRS.closeRegion requires an HRI and the only way to create one is to get it from .META. which in our case doesn't contain a row for that region. Basically we have to wait until that server is dead to get rid of the region and make hbck happy. The required change is to have closeRegion accept an encoded name in both HBA (when the RS address is provided) and HRS since it's able to find it anyways from it's list of live regions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4241) Optimize flushing of the Store cache for max versions and (new) min versions
[ https://issues.apache.org/jira/browse/HBASE-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090773#comment-13090773 ] jirapos...@reviews.apache.org commented on HBASE-4241: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1650/ --- (Updated 2011-08-25 04:49:36.340305) Review request for hbase, Ted Yu, Michael Stack, and Jonathan Gray. Changes --- Added linebreak. Added comment that deletes need to be retained. Summary --- This avoids flushing row versions to disk that are known to be GC'd by the next compaction anyway. This covers two scenarios: 1. maxVersions=N and we find at least N versions in the memstore. We can safely avoid flushing any further versions to disk. 2. similarly minVersions=N and we find at least N versions in the memstore. Now we can safely avoid flushing any further *expired* versions to disk. This changes the Store flush to use the same mechanism that used for compactions. I borrowed some code from the tests and refactored the test code to use a new utility class that wraps a sorted collection and then behaves like KeyValueScanner. The same class is used to create scanner over the memstore's snapshot. This addresses bug HBASE-4241. https://issues.apache.org/jira/browse/HBASE-4241 Diffs (updated) - http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 1161347 http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/util/CollectionBackedScanner.java PRE-CREATION http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/KeyValueScanFixture.java 1161347 http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestKeyValueHeap.java 1161347 http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestKeyValueScanFixture.java 1161347 http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestMinVersions.java 1161347 http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java 1161347 Diff: https://reviews.apache.org/r/1650/diff Testing --- Ran all tests. TestHTablePool and TestDistributedLogSplitting error out (with or without my change). I had to change three tests that incorrectly relied on old rows hanging around after a flush (or were otherwise incorrect). No new test, as this should cause no functional change. Thanks, Lars Optimize flushing of the Store cache for max versions and (new) min versions Key: HBASE-4241 URL: https://issues.apache.org/jira/browse/HBASE-4241 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.92.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Attachments: 4241-v2.txt, 4241.txt As discussed with with Jon, there is room for improvement in how the memstore is flushed to disk. Currently only expired KVs are pruned before flushing, but we can also prune versions if we find at least maxVersions versions in the memstore. The same holds for the new minversion feature: If we find at least minVersion versions in the store we can remove all further versions that are expired. Generally we should use the same mechanism here that is used for Compaction. I.e. StoreScanner. We only need to add a scanner to Memstore that can scan along the current snapshot. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4251) book.xml - adding catalog information in arch section, reorganized schema design, added some extra schema design info
[ https://issues.apache.org/jira/browse/HBASE-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090775#comment-13090775 ] Hudson commented on HBASE-4251: --- Integrated in HBase-TRUNK #2143 (See [https://builds.apache.org/job/HBase-TRUNK/2143/]) HBASE-4251 book.xml (catalog info, reorg of schema design for rowkeys, reorg version info) dmeil : Files : * /hbase/trunk/src/docbkx/book.xml book.xml - adding catalog information in arch section, reorganized schema design, added some extra schema design info - Key: HBASE-4251 URL: https://issues.apache.org/jira/browse/HBASE-4251 Project: HBase Issue Type: Improvement Reporter: Doug Meil Assignee: Doug Meil Priority: Minor Attachments: book_HBASE_4251.xml.patch * Added catalog section in Architecture (ROOT META description, etc.) * Reorganized all the rowkey design entries into a Rowkey Design section. ** Plus, added a sub-section on reverse-timestamps, since that's a fairly common question on the dist-list. ** added small comment on not having an exceedingly high number of versions unless you really, really want all those values (this also came up on the dist-list) * Moved what was added in HBASE-4242 (minimum versions) as a sub-section of the existing version entry. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4217) HRS.closeRegion should be able to close regions with only the encoded name
[
https://issues.apache.org/jira/browse/HBASE-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090776#comment-13090776
]
stack commented on HBASE-4217:
--
This patch is looking good.
I'd say just throw exception here Ram, an NPE which has a message saying
servername can't be null or better an illegalargumentexception (you are
explicit in your javadoc that this can't be null):
{code}
+if (null == serverName) {
+ LOG.error(The server name cannot be null or empty.);
+ return;
+}
{code}
So you add new method to the HRegionInterface. Thats good. Is the
'regionName' param the encoded name or the HRI#getRegionName as bytes? I think
it the former? If so, we should say that in the java doc and change the name
of the param to be encodedName rather than regionName.
We'd do it in Interface and in HRS.
In your closeRegion implementation, seems like you could save some of the work
this method is doing by instead calling the hard to find method
getFromOnlineRegions.
In the shell messing, do we have to add the verb +
close_region_by_encoded_regionname? Its kinda long? Can't we just use current
closeRegion and then by looking at what is passed, figure which method on HBA
to call?
Otherwise, this is excellent Ram.
HRS.closeRegion should be able to close regions with only the encoded name
--
Key: HBASE-4217
URL: https://issues.apache.org/jira/browse/HBASE-4217
Project: HBase
Issue Type: Improvement
Affects Versions: 0.90.4
Reporter: Jean-Daniel Cryans
Assignee: ramkrishna.s.vasudevan
Fix For: 0.92.0
Attachments: HBASE-4217.patch, HBASE-4217_1.patch, HBASE-4217_2.patch
We had some sort of an outage this morning due to a few racks losing power,
and some regions were left in the following state:
ERROR: Region UNKNOWN_REGION on sv4r17s9:60020,
key=e32bbe1f48c9b3633c557dc0291b90a3, not on HDFS or in META but deployed on
sv4r17s9:60020
That region was deleted by the master but the region server never got the
memo. Right now there's no way to force close it because HRS.closeRegion
requires an HRI and the only way to create one is to get it from .META. which
in our case doesn't contain a row for that region. Basically we have to wait
until that server is dead to get rid of the region and make hbck happy.
The required change is to have closeRegion accept an encoded name in both HBA
(when the RS address is provided) and HRS since it's able to find it anyways
from it's list of live regions.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
