[ 
https://issues.apache.org/jira/browse/PHOENIX-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15109318#comment-15109318
 ] 

Thomas D'Silva commented on PHOENIX-2446:
-----------------------------------------

[~jamestaylor] [~lhofhansl]

Calling mvcc.completeMemstoreInsert(mvcc.beginMemstoreInsert())  does not fix 
the issue. 

However if I set the hbase.regionserver.handler.count to 1 which means there is 
one queue and one handler on the region server it fixes the issue. By default 
there are 3 queues and 30 handlers. I think the scan for the index population 
was getting picked up before all the data table batched writes were processed.  
Setting hander count to 1 forces all the batched data table writes that were 
sent to be processed before the index population scan.

> 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, 
> output.log, output_reads.log, output_writes.log, 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)

Reply via email to