[
https://issues.apache.org/jira/browse/HBASE-15698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15302537#comment-15302537
]
Sean Busbey commented on HBASE-15698:
-------------------------------------
Ted. If you're going to email me out of band in an attempt to be polite about
these things, please try to wait more than ~11 hours for a response before you
go ahead and call things out publicly. I don't know what time zone you're in,
but your message came in last night well after I had stopped doing software
related stuff and this update was posted before I had started my day. It's poor
form.
As I mentioned in my email reply to you, I am currently figuring out why our
tests do not fail due to the glaring gap on time ranges Sergey pointed out.
IMHO, it points to a lack in our overall test approach and we need to figure
out if this is an isolated problem or if there's a wider gap between our RPC
handling dependent on codec selection.
Please do attach your patch for reference; I'm happy to have additional authors
on the patch that eventually goes in.
> Increment TimeRange not serialized to server
> --------------------------------------------
>
> Key: HBASE-15698
> URL: https://issues.apache.org/jira/browse/HBASE-15698
> Project: HBase
> Issue Type: Bug
> Affects Versions: 1.2.0, 1.3.0
> Reporter: James Taylor
> Assignee: Sean Busbey
> Priority: Blocker
> Labels: phoenix
> Fix For: 1.3.0, 1.0.4, 1.2.2, 0.98.20, 1.1.6
>
> Attachments: HBASE-15698.1.patch
>
>
> Before HBase-1.2, the Increment TimeRange set on the client was serialized
> over to the server. As of HBase 1.2, this appears to no longer be true, as my
> preIncrement coprocessor always gets HConstants.LATEST_TIMESTAMP as the value
> of increment.getTimeRange().getMax() regardless of what the client has
> specified.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
