[
https://issues.apache.org/jira/browse/PHOENIX-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168261#comment-14168261
]
Lars Hofhansl commented on PHOENIX-1314:
----------------------------------------
Filters are instantiated per store scanner, and with in a store scanner we
should avoid reseeking backwards. Note the *re*seek. Seeking is always OK,
reseeking should only go forward.
HBase has special check for this, which turns backwards reseek into a no-op,
but that's clearly not intended.
We should track down why Phoenix generates these seek keys on the wrong order,
at best performance will suffer (HBase has to detect the no-op, just to do
nothing), at worst this might lead to incorrect data - depending on why Phoenix
generated the seek hints in this order.
Filters must not be shared between scanner at a region server.
> Assertion tripped for skip scan with two unit tests
> ---------------------------------------------------
>
> Key: PHOENIX-1314
> URL: https://issues.apache.org/jira/browse/PHOENIX-1314
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.1
> Reporter: James Taylor
> Assignee: rajeshbabu
> Attachments: PHOENIX-1314.patch
>
>
> After checking in a pretty sizeable change
> (https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=d018cc1c6e01d9836de6e67af4f8b91de3269bfd),
> the assert in SkipScanFilter.setNextCellHint() started getting tripped for
> the following unit tests:
> - DeleteIT.testDeleteAllFromTableWithIndexNoAutoCommitNoSalting()
> - MutableIndexIT.testCoveredColumnUpdatesWithLocalIndex()
> The tests seem to pass without this assert (not sure what HBase does if the
> seek next hint is the same as the current row), but it would be good to get
> to the bottom of this. Would you mind taking a look, [~rajesh23]? It's
> possibly related to PHOENIX-1313.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
