[
https://issues.apache.org/jira/browse/PHOENIX-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-2824:
----------------------------------
Attachment: PHOENIX-2824.patch
Found the cause, [~samarthjain]. Would you mind reviewing? We weren't
maintaining the correct KeyValue order, so when we inserted more than one KV,
we weren't finding it anymore. Essentially, we were getting very luck in that
we were inserting the only one we were looking for.
> PhoenixTransactionalIndexer rollback doesn't work correctly
> -----------------------------------------------------------
>
> Key: PHOENIX-2824
> URL: https://issues.apache.org/jira/browse/PHOENIX-2824
> Project: Phoenix
> Issue Type: Bug
> Reporter: Samarth Jain
> Assignee: James Taylor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2824.patch
>
>
> Looking at this piece of code in PhoenixTransactionalIndexer in
> processRollback(), something isn't right:
> {code}
> do {
> Cell cell = cells.get(i);
> hasPuts |= cell.getTypeByte() ==
> KeyValue.Type.Put.getCode();
> writePtr = cell.getTimestamp();
> do {
> // Add at the beginning of the list to match the
> expected HBase
> // newest to oldest sort order (which
> TxTableState relies on
> // with the Result.getLatestColumnValue() calls).
> singleTimeCells.addFirst(cell);
> } while (++i < nCells && cells.get(i).getTimestamp()
> == writePtr);
> } while (i < nCells && cells.get(i).getTimestamp() <=
> readPtr);
> {code}
> The cell variable isn't being reset in the inner loop even though index i has
> been incremented. As a result we always end up adding cells.get(0) to
> singleTimeCells list. However, simply doing this:
> {code}
> while (++i < nCells && (cell = cells.get(i)).getTimestamp() == writePtr)
> {code}
> unfortunately doesn't work. I see test failures in MutableRollbackIT after
> the above change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
