phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (PHOENIX-5231) Configurable Stats Cache
Date Thu, 30 May 2019 18:09:00 GMT

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

Lars Hofhansl edited comment on PHOENIX-5231 at 5/30/19 6:08 PM:
-----------------------------------------------------------------

The class (DefaultGuidePostsCacheFactory) is present in the embedded client jar. As [~vincentpoon]
points out this the first time we're doing services loading and now are subject to various
class loading idiosyncrasies. In the Presto case it looks like it is a using a different class
loader. We could just say it's Presto's problem, but if this makes it harder we're reducing
the utility of the Phoenix client.

Can we find a different solution? Can we revert this until we have such a solution? I know
it's not what anybody wants to hear :( and it is frustrating having a good idea and spending
time implementing it just to have it removed again - even if temporarily. It just seems to
add extra complexity now to the apps using the Phoenix client, and that is clearly not the
intention.

 


was (Author: lhofhansl):
The class is in the embedded client jar. As [~vincentpoon] points out this the first time
we're doing services loading and now are subject to various class loading idiosyncrasies.
In the Presto case it looks like it is a using a different class loader. We could just say
it's Presto's problem, but if this makes it harder we're reducing the utility of the Phoenix
client.

Can we find a different solution? Can we revert this until we have such a solution? I know
it's not what anybody wants to hear :( and it is frustrating having a good idea and spending
time implementing it just to have it removed again - even if temporarily. It just seems to
add extra complexity now to the apps using the Phoenix client, and that is clearly not the
intention.

 

> Configurable Stats Cache
> ------------------------
>
>                 Key: PHOENIX-5231
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-5231
>             Project: Phoenix
>          Issue Type: Test
>            Reporter: Daniel Wong
>            Assignee: Daniel Wong
>            Priority: Major
>             Fix For: 4.15.0, 5.1.0
>
>         Attachments: 5231-quickfix-v2.txt, 5231-quickfix.txt, 5231-services-fix.patch,
PHOENIX-5231.4.x-HBase-1.3.patch, PHOENIX-5231.4.x-HBase-1.3.v2.patch, PHOENIX-5231.4.x-HBase-1.3.v3.patch,
PHOENIX-5231.master.v3.patch, PHOENIX-5231.master.v4.patch
>
>          Time Spent: 8h 40m
>  Remaining Estimate: 0h
>
> Currently, the phoenix stats cache is per ConnectionQuerySerivce/ConnectionProfile, which
leads to duplicated cached entry (the guideposts) and waste resources if these separate connections
are querying the same underlying table. It would be good to be able to provide a configurable
stats cache as control the cache level so it could be per JVM.



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

Mime
View raw message