[
https://issues.apache.org/jira/browse/HBASE-15698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315584#comment-15315584
]
Andrew Purtell edited comment on HBASE-15698 at 6/4/16 5:31 PM:
----------------------------------------------------------------
So the difference in the test between v3 and v4 is instead of:
{code}
+ TimeRange range2 = new TimeRange(1,
EnvironmentEdgeManager.currentTime()+2);
+ List<Row> actions =
+ Arrays.asList(new Row[] { new Increment(ROW_A).addColumn(TEST_FAMILY,
qualifierCol1, 2L)
+ .setTimeRange(range2.getMin(), range2.getMax()),
+ new Increment(ROW_A).addColumn(TEST_FAMILY, qualifierCol1, 2L)
+ .setTimeRange(range2.getMin(), range2.getMax()) });
+ Object[] results3 = new Object[actions.size()];
+ Object[] results1 = results3;
+ hTableInterface.batch(actions, results1);
+ assertEquals(MyObserver.tr2.getMin(), range2.getMin());
+ assertEquals(MyObserver.tr2.getMax(), range2.getMax());
+ assertEquals(2, results1.length);
+ for (Object r2 : results1) {
+ assertTrue(r2 instanceof Result);
+ }
+ checkRowValue(ROW_A, Bytes.toBytes(15L));
{code}
instead only one increment is submitted by batch() and the test for expected
total is adjusted:
{code}
+ TimeRange range2 = new TimeRange(1,
EnvironmentEdgeManager.currentTime()+2);
+ List<Row> actions =
+ Arrays.asList(new Row[] { new Increment(ROW_A).addColumn(TEST_FAMILY,
qualifierCol1, 2L)
+ .setTimeRange(range2.getMin(), range2.getMax()) });
+ Object[] results3 = new Object[actions.size()];
+ Object[] results1 = results3;
+ hTableInterface.batch(actions, results1);
+ assertEquals(MyObserver.tr2.getMin(), range2.getMin());
+ assertEquals(MyObserver.tr2.getMax(), range2.getMax());
+ for (Object r2 : results1) {
+ assertTrue(r2 instanceof Result);
+ }
+ checkRowValue(ROW_A, Bytes.toBytes(13L));
{code}
[~tedyu] can you explain why the first version of the test failed? I assumed it
passed for you on your local dev box? Is this a bug or unexpected behavior with
increment? Or is this just going to be a flaky test because it's using
System#currentTimeMillis as clock source (the default EnvironmentEdge) with
really small timeranges? It would be better to inject the ManualEnvironmentEdge
and control the clock used for the test manually, I think.
was (Author: apurtell):
So the difference in the test between v3 and v4 is instead of:
{code}
+ TimeRange range2 = new TimeRange(1,
EnvironmentEdgeManager.currentTime()+2);
+ List<Row> actions =
+ Arrays.asList(new Row[] { new Increment(ROW_A).addColumn(TEST_FAMILY,
qualifierCol1, 2L)
+ .setTimeRange(range2.getMin(), range2.getMax()),
+ new Increment(ROW_A).addColumn(TEST_FAMILY, qualifierCol1, 2L)
+ .setTimeRange(range2.getMin(), range2.getMax()) });
+ Object[] results3 = new Object[actions.size()];
+ Object[] results1 = results3;
+ hTableInterface.batch(actions, results1);
+ assertEquals(MyObserver.tr2.getMin(), range2.getMin());
+ assertEquals(MyObserver.tr2.getMax(), range2.getMax());
+ assertEquals(2, results1.length);
+ for (Object r2 : results1) {
+ assertTrue(r2 instanceof Result);
+ }
+ checkRowValue(ROW_A, Bytes.toBytes(15L));
{code}
instead only one increment is submitted by batch() and the test for expected
total is adjusted:
{code}
+ TimeRange range2 = new TimeRange(1,
EnvironmentEdgeManager.currentTime()+2);
+ List<Row> actions =
+ Arrays.asList(new Row[] { new Increment(ROW_A).addColumn(TEST_FAMILY,
qualifierCol1, 2L)
+ .setTimeRange(range2.getMin(), range2.getMax()) });
+ Object[] results3 = new Object[actions.size()];
+ Object[] results1 = results3;
+ hTableInterface.batch(actions, results1);
+ assertEquals(MyObserver.tr2.getMin(), range2.getMin());
+ assertEquals(MyObserver.tr2.getMax(), range2.getMax());
+ for (Object r2 : results1) {
+ assertTrue(r2 instanceof Result);
+ }
+ checkRowValue(ROW_A, Bytes.toBytes(13L));
{code}
[~tedyu] can you explain why the first version of the test failed? I assumed it
passed for you on your local dev box? Is this a bug or unexpected behavior with
increment? Or is this just going to be a flaky test because it's using
System#currentTimeMillis as clock source with really small timeranges? It would
be better to inject the ManualEnvironmentEdge and control the clock used for
the test manually, I 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)
