[
https://issues.apache.org/jira/browse/PHOENIX-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-2446:
----------------------------------
Attachment: PHOENIX-2446_testfix.patch
[~tdsilva] - I attached a fix for the transactional case of this issue over on
PHOENIX-2478. I'm also attaching a modified version of your test with a couple
of minor tweaks:
- create the index with an IF NOT EXISTS clause, as the coprocessor will fire
again when we replay the transaction and we'd get an error if it already existed
- throw a DoNotRetryIOException from the coprocessor as you don't want to
trigger the 30x retry loop of HBase
- lower the number of rows - you don't need to create many rows to repro given
the way you've setup the test
- query the table with no hint (as it'll use the index). The old code would
have been fine too, but it didn't include the schema name of the index.
It passes now, but only when transactional is true.
> Immutable index - Index vs base table row count does not match when index is
> created during data load
> -----------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-2446
> URL: https://issues.apache.org/jira/browse/PHOENIX-2446
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.6.0
> Reporter: Mujtaba Chohan
> Assignee: Thomas D'Silva
> Fix For: 4.7.0
>
> Attachments: PHOENIX-2446-wip-v3.patch, PHOENIX-2446-wip.patch,
> PHOENIX-2446.patch, PHOENIX-2446_partial.patch, PHOENIX-2446_testfix.patch,
> server.log
>
>
> I'll add more details later but here's the scenario that consistently
> produces wrong row count for index table vs base table for immutable async
> index.
> 1. Start data upsert
> 2. Create async index
> 3. Trigger M/R index build
> 4. Keep data upsert going in background during step 2,3 and a while after M/R
> index finishes.
> 5. End data upsert.
> Now count with index enabled vs count with hint to not use index is off by a
> large factor. Will get a cleaner repro for this issue soon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)