phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samarth Jain (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4021) Remove CachingHTableFactory
Date Fri, 14 Jul 2017 02:20:00 GMT

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

Samarth Jain commented on PHOENIX-4021:
---------------------------------------

[~gjacoby] - one option for you would be to create a table factory in the start() method of
the Indexer co-processor. The factory would internally cache the HConnection and have methods
to dole out HTable. The stop() method of the co-processor would close the table factory which
in turn will close the HConnection. A possibility for you would be to use IndexWriterUtils#CoprocessorHConnectionTableFactory
which is thread safe too. It would need slight refactoring as it is currently meant to be
used as a delegate in CachingHTableFactory.

> 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)

Mime
View raw message