[
https://issues.apache.org/jira/browse/HBASE-15698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315595#comment-15315595
]
Ted Yu commented on HBASE-15698:
--------------------------------
The 1 test run for v3 and 2 test runs for v4 passed on QA bot.
I would say the formation of test in v3 leads to flaky test.
bq. is this just going to be a flaky test because it's using
System#currentTimeMillis
The above is a possible scenario.
I also want to point out that the failed assertion was on check for value, not
whether the TimeRange is correctly delivered to the server side which was the
cause for regression in the first place.
Looking back on the test in v3, it doesn't make sense to send two Increments
for the same row, family and qualifier in one batch.
bq. It would be better to inject the ManualEnvironmentEdge
Can you elaborate a bit more on where the injection takes place ?
In v4, code paths for passing TimeRange in both table.increment() and
table.batch() are covered.
I can add an Increment for ROW_B in the same batch call and verify the value
afterwards. What do you think ?
> 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: Ted Yu
> Priority: Blocker
> Labels: phoenix
> Fix For: 1.3.0, 1.4.0, 1.2.2, 0.98.20, 1.1.6
>
> Attachments: 15698-suggest.txt, 15698.v1.txt, 15698.v2.txt,
> 15698.v3.txt, 15698.v4.txt, 15698.v4.txt, 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)
