[
https://issues.apache.org/jira/browse/PHOENIX-2885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15376972#comment-15376972
]
Lars Hofhansl commented on PHOENIX-2885:
----------------------------------------
I think as long as we get the cache refresh out of the synchronous path for
each query we're good.
10s seems like an excellent default for most but the biggest installs. Even
with 100 client processes, we'd do at most 10 cache updates/sec/table. With
1000's of clients we'd need a longer delay.
Making everything detectable is tricky. The absence of stuff is always hard to
prove. We'd have to pass down what we expect to exist, then match at the server
(for example in the SELECT * case, we'd pass the columns we expect, if we find
a Cell with an unexpected column we could fail the query... quite tricky).
I looked at bit at the default setting. Doing that after the fact is not that
easy either, since the value of 0 is written into the CATALOG table, and hence
we cannot distinguish ALWAYS from "nothing set". We could override that default
for new installs, and/or upgrade that to 10s during an upgrade.
> Refresh client side cache before throwing not found exception
> -------------------------------------------------------------
>
> Key: PHOENIX-2885
> URL: https://issues.apache.org/jira/browse/PHOENIX-2885
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Fix For: 4.9.0
>
>
> With the increased usage of the UPDATE_CACHE_FREQUENCY property to reduce
> RPCs, we increase the chance that a separate client attempts to access a
> column that doesn't exist on the cached entity. Instead of throwing in this
> case, we can update the client-side cache. This works well for references to
> entities (columns, tables) that don't yet exist. For entities that *do*
> exist, we won't detect that they've been deleted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
