[
https://issues.apache.org/jira/browse/PHOENIX-5231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852259#comment-16852259
]
Lars Hofhansl commented on PHOENIX-5231:
----------------------------------------
I love the idea. And I learned something as I didn't know how the "services"
framework works. I think we just need to fully understand the
shading/classloading implications. Perhaps this has to do partial shading and
classloading getting confused due to that?
[~vincentpoon], wdyt? Should we try to resolve the problem now, or revert first
and then regroup?
In any case I am only suggesting reverting from 4.15.x. We should leave it in
5.1.x.
> 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)
