[
https://issues.apache.org/jira/browse/PHOENIX-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoffrey Jacoby updated PHOENIX-4021:
-------------------------------------
Attachment: PHOENIX-4021.patch
Attaching this first draft patch for discussion. It removes
CachingHTableFactory but does not replace it with any coprocessor HConnection
caching, so while this will solve the potential race condition, there might be
a performance regression from making new HConnections each time.
[~samarthjain], [~vincentpoon] [~jamestaylor], your thoughts on how best to
make the server->server RPCs cache HConnections? Perhaps something like
PHOENIX-3611, but simpler and for HConnections rather than
ConnectionQueryServices?
> Remove CachingHTableFactory
> ---------------------------
>
> Key: PHOENIX-4021
> URL: https://issues.apache.org/jira/browse/PHOENIX-4021
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.11.0
> Reporter: Geoffrey Jacoby
> Assignee: Geoffrey Jacoby
> Labels: globalMutableSecondaryIndex
> Fix For: 4.12.0
>
> Attachments: PHOENIX-4021.patch
>
>
> CachingHTableFactory is used as a performance optimization when writing to
> global indexes so that HTable instances are cached and later automatically
> cleaned up, rather than instantiated each time we write to an index.
> This should be removed for two reasons:
> 1. It opens us up to race conditions, because HTables aren't threadsafe, but
> CachingHTableFactory doesn't guard against two threads both grabbing the same
> HTable and using it simultaneously. Since all ops going through a region
> share the same IndexWriter and ParallelWriterIndexCommitter, and hence the
> same CachingHTableFactory, that means separate operations can both be holding
> the same HTable.
> 2. According to discussion on PHOENIX-3159, and offline discussions I've had
> with [~apurtell], HBase 1.x and above make creating throwaway HTable
> instances cheap so the caching is no longer needed.
> For 4.x-HBase-1.x and master, we should remove CachingHTableFactory, and for
> 4.x-HBase-0.98, we should either get rid of it (if it's not too much of a
> perf hit) or at least make it threadsafe.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
