[
https://issues.apache.org/jira/browse/PHOENIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750459#comment-16750459
]
Hadoop QA commented on PHOENIX-5069:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12956017/PHOENIX-5069.master.003.patch
against master branch at commit c8686ce73093b879bbda5f08f3e7933a9708e110.
ATTACHMENT ID: 12956017
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 release audit{color}. The applied patch generated 1 release
audit warnings (more than the master's current 0 warnings).
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ // 1. Load stats from the stats table only when the stats get
updated on the server side.
+ public GuidePostsInfo loadStats(GuidePostsKey statsKey, GuidePostsInfo
prevGuidepostInfo) throws Exception {
+ new Object[] {Objects.hashCode(GuidePostsCache.this),
key, info.getEstimatedSize()});
+ public GuidePostsInfo loadStats(GuidePostsKey statsKey, GuidePostsInfo
prevGuidepostInfo) throws Exception {
+ logger.warn("Unable to load stats from table:
" + key.toString(), e);
+ * @param prevGuidepostInfo the existing stats cached on the client side
or GuidePostsInfo.NO_GUIDEPOST
+ GuidePostsInfo loadStats(GuidePostsKey statsKey, GuidePostsInfo
prevGuidepostInfo) throws Exception;
+ // Those Java equivalents of sizeof() in C/C++, mentioned on the Web,
might be overkilled here.
+ + SizedUtil.ARRAY_SIZE + this.gpTimestamps.length *
SizedUtil.LONG_SIZE // gpTimestamps
+ public TestStatsLoaderImpl(CountDownLatch firstTimeRefreshedSignal,
CountDownLatch secondTimeRefreshedSignal) {
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexSplitReverseScanIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.PartialIndexRebuilderIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexFailureWithNamespaceIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ConcurrentMutationsIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexSplitForwardScanIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.join.HashJoinMoreIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/2270//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/2270//artifact/patchprocess/patchReleaseAuditWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/2270//console
This message is automatically generated.
> 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.master.001.patch,
> PHOENIX-5069.master.002.patch, PHOENIX-5069.master.003.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)
