[
https://issues.apache.org/jira/browse/HBASE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578914#action_12578914
]
stack commented on HBASE-514:
-----------------------------
This complicated patch is missing commit message.
I like the way you removed it from HRegionInterface and removed ts. Should it
be package private in HRegion?
HashSet is not used in HStore
Why are we not allows searching w/ 'key'? Why are we using the earliest key?
{code}
// we want the earliest possible to start searching from
|
}
HStoreKey search_key = candidateKeys.isEmpty() ?
|
}
new HStoreKey(key) : new HStoreKey(candidateKeys.first().getRow());
{code}
Regards your strip timestamp method, creating a new HSK is safest but do you
need to create a new instance? (Could setVersion on current hsk).
Do you think candidateKeys size could be large or the aggregate of the values
would blow memory? Do we have to carry the values? Can we get away with just
yes no on whether a delete value or not?
Whas happening here?
{code}
if (found_key.getRow().compareTo(key) <= 0) {
if (HLogEdit.isDeleted(tailMap.get(found_key))) {
candidateKeys.remove(stripTimestamp(found_key));
{code}
Deletes cells only delete cells of same r/c/ts combo. Here you are deleting
any key that has same r/c without regard for ts -- including cells newer than
the found_key. Is that intentional? (Happens in two places)
Incomplete comment: + // empty. examine all the keys of the
In this code:
{code}
// if the last row we found a candidate key for is different than
// the row of the current candidate, we can stop looking.
if (lastRowFound != null &&
!lastRowFound.equals(thisKey.getRow())) {
break;
}
{code}
Why break, why not keeping moving forward till we get even closer to the passed
in key?
Remove commented out code.
Is the return premature in below or is rationale that because mapfiles are
sorted, we look at first one and its last key is 'highest' for this store?
{code}
if (finalKey.getRow().compareTo(row) < 0) {
candidateKeys.add(stripTimestamp(finalKey));
return;
}
{code}
Unit tests in branch all test. I ran a randomWrite -- thinking randomWriting
would exercise this patch -- PE with 4 clients and it succeeded (8 clients
OOME'd though heap of 1.6G). Means that you haven't broken anything it seems.
> table 'does not exist' when it does
> -----------------------------------
>
> Key: HBASE-514
> URL: https://issues.apache.org/jira/browse/HBASE-514
> Project: Hadoop HBase
> Issue Type: Bug
> Components: client
> Affects Versions: 0.16.0
> Reporter: stack
> Fix For: 0.1.0
>
> Attachments: 514-0.1-v2.patch, 514-0.1.patch, region-v2.patch
>
>
> This one I've seen a few times. In hql, I do show tables and it shows my
> table. I then try to do a select against the table and hql reports table
> does not exist. Digging, whats happening is that the getClosest facility is
> failing to find the first table region in the .META. table. I hacked up a
> region reading tool -- attached (for 0.1 branch) -- and tried it against but
> a copy and the actual instance of the region and it could do the getClosest
> fine. I'm pretty sure I restarted the HRS and when it came up again, the
> master had given it again the .META. and again was failing to find the first
> region in the table (Looked around in server logs and it seemed 'healthy').
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
