[
https://issues.apache.org/jira/browse/PHOENIX-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15341717#comment-15341717
]
James Taylor commented on PHOENIX-3015:
---------------------------------------
The drop of the local index should update the cache, but only if the drop is
done from the same client. We could create a new variant of
{{PhoenixRuntime.getTable}} that always pings the server for the latest by
calling {{new MetaDataClient(pconn).updateCache(schemaName, tableName, true);}}
before attempting to get the table from the cache.
> Any metadata changes may cause unpredictable result when local indexes are
> using
> --------------------------------------------------------------------------------
>
> Key: PHOENIX-3015
> URL: https://issues.apache.org/jira/browse/PHOENIX-3015
> Project: Phoenix
> Issue Type: Bug
> Reporter: Sergey Soldatov
> Priority: Critical
>
> The problem code is in
> IndexHalfStoreFileReaderGenerator#preStoreFileReaderOpen:
> {noformat}
> conn =
> QueryUtil.getConnection(ctx.getEnvironment().getConfiguration()).unwrap(
> PhoenixConnection.class);
> PTable dataTable = PhoenixRuntime.getTable(conn,
> tableName.getNameAsString());
> {noformat}
> Use case:
> 1. create table & local index. Load some data.
> 2. Call split.
> 3a. Add new local index.
> 3b. Drop local index and recreate it.
> 4. Call split.
> When the earlier mentioned code is executed during (2) it caches table into
> ConnectionQueryServicesImpl#latestMetaData . When it is executed during (4)
> dataTable is getting from cache and doesn't reflect information after (3a) or
> (3b). As the result the data for last created index will be lost during the
> split because of absence of index maintainer.
> After looking into ConnectionQueryServicesImpl I don't understand how the
> cache was supposed to be updated, so any suggestions/comments are really
> appreciated.
> [~jamestaylor], [~rajeshbabu] FYI
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
