[
https://issues.apache.org/jira/browse/HBASE-6341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408366#comment-13408366
]
Micah Whitacre commented on HBASE-6341:
---------------------------------------
As I indicated above the common use case we have is to maintain a cache of
Configuration -> HTablePool instances. In the our processing infrastructure
(Storm) Hadoop Configuration objects are serialized and passed into the
processing workers. Instead of creating new HTable instances we'd like to
reuse HTablePool instances to retrieve existing HTableInterface instances.
Since the Configuration objects are new instances we can't use a
Map<Configuration, HTablePool> to reuse HTablePool instances and HConnectionKey
would fill that gap nicely. Additionally if we don't cache HTablePool
instances we'd lose the benefit of reusing connections because we'd end up with
multiple HTablePool instances containing one pooled table.
We have other similar higher order constructs which take a Configuration and it
would be nice to reuse instances which interact with the same underlying
HBaseTableInterface/Pool instance.
I've seen this elsewhere in discussions but essentially we need an efficient
way to identify a Configuration object represents the same underlying HBase
cluster. I don't have a link handy but I remember seeing conversations which
talked about adding a "uniquifier" to Configuration and I perceived the
HConnectionKey to be the resolution to that. If there is a better solution for
solving that I'd be willing to adopt that.
> Publicly expose HConnectionKey
> ------------------------------
>
> Key: HBASE-6341
> URL: https://issues.apache.org/jira/browse/HBASE-6341
> Project: HBase
> Issue Type: Improvement
> Components: client
> Affects Versions: 0.92.0
> Reporter: Micah Whitacre
> Priority: Trivial
> Attachments: hbase_6341.patch
>
>
> HBASE-3777 introduced the concept of a HConnectionKey to quickly identify and
> compare Configuration instances which lack equals/hashCode values.
> We currently have use cases where being able to key Configuration objects in
> a similar way would be helpful. An example of this would be maintain a cache
> of HTablePool instances based on the HConnectionKey instead of the
> Configuration instance.
> I propose that HConnectionKey be made publicly available instead of its
> current package scope. Or another possibility would be to move it from being
> a static inner class to being part of the API.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
