[
https://issues.apache.org/jira/browse/HBASE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405028#comment-13405028
]
Hudson commented on HBASE-6265:
-------------------------------
Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #77 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/77/])
HBASE-6265 Calling getTimestamp() on a KV in cp.prePut() causes KV not to
be flushed (Revision 1356106)
Result = FAILURE
larsgeorge :
Files :
* /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/KeyValue.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/TestKeyValue.java
> Calling getTimestamp() on a KV in cp.prePut() causes KV not to be flushed
> -------------------------------------------------------------------------
>
> Key: HBASE-6265
> URL: https://issues.apache.org/jira/browse/HBASE-6265
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 0.92.0, 0.94.0, 0.96.0
> Reporter: Lars George
> Assignee: Lars George
> Priority: Critical
> Fix For: 0.92.2, 0.96.0, 0.94.1
>
> Attachments: HBASE-6265-0.92.patch, HBASE-6265-0.94.patch,
> HBASE-6265-v2.patch, HBASE-6265-v3.patch, HBASE-6265.patch
>
>
> There is an issue when you call getTimestamp() on any KV handed into a
> Coprocessor's prePut(). It initializes the internal "timestampCache"
> variable.
> When you then pass it to the normal processing, the region server sets the
> time to the server time in case you have left it unset from the client side
> (updateLatestStamp() call).
> The TimeRangeTracker then calls getTimestamp() later on to see if it has to
> include the KV, but instead of getting the proper time it sees the cached
> timestamp from the prePut() call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
