phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-5069) Use asynchronous refresh to provide non-blocking Phoenix Stats Client Cache
Date Wed, 16 Jan 2019 01:51:00 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743538#comment-16743538
] 

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/12955021/PHOENIX-5069.master.001.patch
  against master branch at commit 3bd426f10337b6e109ab7394bd4a4023039fd0e8.
  ATTACHMENT ID: 12955021

    {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.MutableIndexFailureWithNamespaceIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.execute.PartialCommitIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexSplitReverseScanIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexFailureIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.tx.TxCheckpointIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.GlobalMutableTxIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.tx.ParameterizedTransactionIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.NonColumnEncodedImmutableTxStatsCollectorIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.txn.RollbackIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.TransactionalViewIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.tx.TransactionIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ConcurrentMutationsIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.GlobalImmutableTxIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.StatsEnabledSplitSystemCatalogIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.tx.FlappingTransactionIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.txn.TxWriteFailureIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.ImmutableIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ViewIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.txn.MutableRollbackIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.IndexToolIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.SysTableNamespaceMappedStatsCollectorIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.rpc.UpdateCacheIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexSplitForwardScanIT

Test results: https://builds.apache.org/job/PreCommit-PHOENIX-Build/2245//testReport/
Release audit warnings: https://builds.apache.org/job/PreCommit-PHOENIX-Build/2245//artifact/patchprocess/patchReleaseAuditWarnings.txt
Console output: https://builds.apache.org/job/PreCommit-PHOENIX-Build/2245//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.patch
>
>          Time Spent: 3h
>  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] [~twdsilva@gmail.com] [~dbwong] [~elserj] [~ankit@apache.org] [~sergey
soldatov] 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message