[
https://issues.apache.org/jira/browse/HBASE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578922#action_12578922
]
Bryan Duxbury commented on HBASE-514:
-------------------------------------
> Why are we not allows searching w/ 'key'? Why are we using the earliest key?
If there are any keys in the candidateKeys, then we want to start with the
first one in there. If there are keys in candidateKeys, then they are
guaranteed to be <= the search row's key. We need to start as early as possible
because we also want to scan over regions where there might be deletes for
candidates from earlier on. If we always just started at the search row, we
wouldn't know if earlier candidate keys had been suppressed later on.
> 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).
I have no problem changing this method. Figuring cut down on object creations?
> 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?
We do not carry the values, just the keys. If the keys happen to be very large,
then there is the possibility of using up lots of memory. Moreover, the idea is
that when we encounter a delete, we'll use that event to remove the key that
corresponds to it from the set of candidate keys. The candidate keys set should
grow and shrink as we find and entertain more candidate keys.
> In this code: ...
Actually, in this case, we're iterating through the map backwards, so once
we've found one row that survives the whole way, then we've found the closest
row already, and should stop looking.
> 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?
Yes.
> 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.
