[
https://issues.apache.org/jira/browse/PHOENIX-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15109931#comment-15109931
]
James Taylor commented on PHOENIX-2478:
---------------------------------------
[~mujtabachohan] - I tracked down why we're sending so much info to Tephra. We
weren't marking the index as immutable so we ended up sending all the row keys
of the index to Tephra to do conflict resolution. This is fixed in PHOENIX-2616.
[~poornachandra] - would still be good to follow up on this. We're using a
batch size of 5000 rows when we commit, so we'd expect the defaults to handle
this fine.
> Rows committed in transaction overlapping index creation are not populated
> --------------------------------------------------------------------------
>
> Key: PHOENIX-2478
> URL: https://issues.apache.org/jira/browse/PHOENIX-2478
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: James Taylor
> Assignee: James Taylor
> Fix For: 4.7.0
>
> Attachments: PHOENIX-2478.patch, PHOENIX-2478_addendum.patch,
> PHOENIX-2478_addendum2.patch, PHOENIX-2478_addendum3.patch,
> PHOENIX-2478_addendum4.patch, PHOENIX-2478_v2.patch, PHOENIX-2478_v3.patch,
> PHOENIX-2478_v4.patch
>
>
> For a reproducible case, see IndexIT.testCreateIndexAfterUpsertStarted() and
> the associated FIXME comments for PHOENIX-2446.
> The case that is failing is when a commit starts before an index exists, but
> commits after the index build is completed. For transactional data, this is
> problematic because the index gets a timestamp after the commit of the data
> table mutation and thus these mutations won't be seen during the commit.
> Also, when the index is being built, the data hasn't yet been committed and
> thus won't be part of the initial index build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
