[
https://issues.apache.org/jira/browse/PHOENIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16766647#comment-16766647
]
Hudson commented on PHOENIX-5069:
---------------------------------
FAILURE: Integrated in Jenkins build PreCommit-PHOENIX-Build #2330 (See
[https://builds.apache.org/job/PreCommit-PHOENIX-Build/2330/])
PHOENIX-5069 Use asynchronous refresh to provide non-blocking Phoenix
(karanmehta93: rev 982b09adb43e8f837b5e6a2cd23921ec08e33065)
* (add)
phoenix-core/src/test/java/org/apache/phoenix/query/PhoenixStatsCacheLoaderTest.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/schema/stats/GuidePostsInfo.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/query/GuidePostsCache.java
* (add)
phoenix-core/src/main/java/org/apache/phoenix/query/PhoenixStatsCacheLoader.java
* (add)
phoenix-core/src/main/java/org/apache/phoenix/query/PhoenixStatsLoader.java
* (edit) phoenix-core/src/main/java/org/apache/phoenix/query/QueryServices.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/query/QueryServicesOptions.java
> Use asynchronous refresh to provide non-blocking Phoenix Stats Client Cache
> ---------------------------------------------------------------------------
>
> Key: PHOENIX-5069
> URL: https://issues.apache.org/jira/browse/PHOENIX-5069
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Bin Shi
> Assignee: Bin Shi
> Priority: Major
> Attachments: PHOENIX-5069-4.14.1-hbase-1.3-phoenix-stats.001.patch,
> PHOENIX-5069-4.14.1-hbase-1.3-phoenix-stats.002.patch,
> PHOENIX-5069.4.x-HBase-1.4.001.patch, PHOENIX-5069.master.001.patch,
> PHOENIX-5069.master.002.patch, PHOENIX-5069.master.003.patch,
> PHOENIX-5069.master.004.patch, PHOENIX-5069.patch
>
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> The current Phoenix Stats Cache uses TTL based eviction policy. A cached
> entry will expire after a given amount of time (900s by default) passed since
> the entry's been created. This will lead to cache miss when
> Compiler/Optimizer fetches stats from cache at the next time. As you can see
> from the above graph, fetching stats from the cache is a blocking operation —
> when there is cache miss, it has a round trip over the wire to scan the
> SYSTEM.STATS Table and to get the latest stats info, rebuild the cache and
> finally return the stats to the Compiler/Optimizer. Whenever there is a cache
> miss, this blocking call causes significant performance penalty and see
> periodic spikes.
> *This Jira suggests to use asynchronous refresh mechanism to provide a
> non-blocking cache. For details, please see the linked design document below.*
> [~karanmehta93] [[email protected]] [~dbwong] [~elserj] [[email protected]]
> [~sergey soldatov]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
