[
https://issues.apache.org/jira/browse/PHOENIX-3823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maddineni Sukumar updated PHOENIX-3823:
---------------------------------------
Attachment: PHOENIX-3823.v9.patch
Created new patch as old patch did not apply properly due to other latest
commits.
> Force cache update on MetaDataEntityNotFoundException
> ------------------------------------------------------
>
> Key: PHOENIX-3823
> URL: https://issues.apache.org/jira/browse/PHOENIX-3823
> Project: Phoenix
> Issue Type: Sub-task
> Affects Versions: 4.10.0
> Reporter: James Taylor
> Assignee: Maddineni Sukumar
> Fix For: 4.11.0
>
> Attachments: PHOENIX-3823.patch, PHOENIX-3823.v2.patch,
> PHOENIX-3823.v3.patch, PHOENIX-3823.v4.patch, PHOENIX-3823.v5.patch,
> PHOENIX-3823.v6.patch, PHOENIX-3823.v7.patch, PHOENIX-3823.v8.patch,
> PHOENIX-3823.v9.patch
>
>
> When UPDATE_CACHE_FREQUENCY is used, clients will cache metadata for a period
> of time which may cause the schema being used to become stale. If another
> client adds a column or a new table or view, other clients won't see it. As a
> result, the client will get a MetaDataEntityNotFoundException. Instead of
> bubbling this up, we should retry after forcing a cache update on the tables
> involved in the query.
> The above works well for references to entities that don't yet exist.
> However, we cannot detect when some entities are referred to which no longer
> exists until the cache expires. An exception is if a physical table is
> dropped which would be detected immediately, however we would allow queries
> and updates to columns which have been dropped until the cache entry expires
> (which seems like a reasonable tradeoff IMHO. In addition, we won't start
> using indexes on tables until the cache expires.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
