phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoffrey Jacoby (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4025) Make CachingHTableFactory thread-safe for 0.98 branch
Date Fri, 14 Jul 2017 17:58:00 GMT

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

Geoffrey Jacoby commented on PHOENIX-4025:
------------------------------------------

[~jamestaylor] - if that's the case, I'm all for getting rid of it everywhere too. Getting
CachingHTableFactory to be thread-safe is possible but definitely non-trivial -- lots of edge
cases in distinguishing cache eviction from normal user release.

> Make CachingHTableFactory thread-safe for 0.98 branch
> -----------------------------------------------------
>
>                 Key: PHOENIX-4025
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4025
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.11.0
>            Reporter: Geoffrey Jacoby
>            Assignee: Geoffrey Jacoby
>             Fix For: 4.12.0
>
>
> CachingHTableFactory, which is used in global index writes, isn't thread-safe (see discussion
in PHOENIX-4021) and will be removed in the master and 4.x-HBase-1.x branches. However, according
to PHOENIX-3159 it's still needed in HBase 0.98-based Phoenix because creating HTables is
still heavy-weight in 0.98. 
> This means it needs to be made thread-safe. Current plan is when an HTable's requested,
check the reference count (which is already tracked for cleanup purposes) and if the count
is 1, create a new HTable. We'll cache lists of identical HTables per HBase table, rather
than 1 HTable per HBase table. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message