You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2010/01/22 20:04:22 UTC
[jira] Updated: (HBASE-2157) LATEST_TIMESTAMP not replaced by
current timestamp in KeyValue
[ https://issues.apache.org/jira/browse/HBASE-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HBASE-2157:
-------------------------
Attachment: 2157.patch
I added note to the bulk load documentation that warns against creating KVs w/o explicit timestamp so others don't trip over Menno's issue.
> LATEST_TIMESTAMP not replaced by current timestamp in KeyValue
> --------------------------------------------------------------
>
> Key: HBASE-2157
> URL: https://issues.apache.org/jira/browse/HBASE-2157
> Project: Hadoop HBase
> Issue Type: Bug
> Affects Versions: 0.20.2
> Environment: Hadoop 0.20.0 - Hbase 0.20.2 - Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Reporter: Menno Luiten
> Attachments: 2157.patch
>
>
> I was trying to bulk load using the new HFileOutputFormat. When using a MapReduce in which map generates {{KeyValue}}s and reduce is equal to KeyValueSortReducer, and using the constructor using (byte[] row, byte[] family, byte[] qualifier, byte[] value), the (undefined) timestamp was inserted as HConstants.LATEST_TIMESTAMP/Long.MAX_VALUE into HBase. This causes all kinds of troubles, but most importantly, while the records were in the table, other MapReduces (using TableInputFormat) and Hbase shell's 'get'-command did not fetch them. Guess there is some sort of filtering of future dates.
> As I understood from St.Ack, the LASTEST_TIMESTAMP is supposed to be replaced by System.currentTimeMillis(), but I don't see this reflected in the code of KeyValue, and apparently it did not happen elsewhere; perhaps because there is no actual HBase connection?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.