[
https://issues.apache.org/jira/browse/HBASE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578950#action_12578950
]
Jim Kellerman commented on HBASE-514:
-------------------------------------
I found instances where we delete cells using TIMESTAMP_LATEST, hence
stripping timestamps is absolutely the right thing to do.
- HMaster$ChangeTableState.postProcessMeta
- HRegion.offlineRegionInMETA
The following should call deleteAll:
- HMerge${OfflineMerger,OnlineMerger).updateMeta
- DisabledTestScanner2.removeRegionFromMETA
HStore:
- public method HStore$Memcache.getRowKeyAtOrBefore is missing javadoc for
parameters and exceptions
- stripTimestamp should be package private and not private because it causes
synthetic accessors to be generate so Memcache can access it. Will also make
port to trunk easier
- public method HStore.getRowKeyAtOrBefore is missing javadoc for parameters,
return value and exceptions thrown, also remove commented code.
- unnecessary else at line 1869
- comments should include examples to show why scanning from oldest to newest
is important. We'll all have forgotten why 6 months from now.
> stack - 14/Mar/08 01:01 PM
> This complicated patch is missing commit message.
+1
> HashSet is not used in HStore
Neither is Set
> 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).
If you did setVersion on current HSK, then you would be invalidating
the map that it was being read from (memcache or snapshot)
> 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.
