[
https://issues.apache.org/jira/browse/HBASE-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790243#action_12790243
]
Dave Latham commented on HBASE-2036:
------------------------------------
This looks like a good idea.
It relates to HBASE-2027 and some other issues that deal with how HConnection's
are cached by the client. Right now, they use HBaseConfiguration as a key to a
set of cached connections and information. It looks like the patch removes
equals() from HBaseConfiguration (but not hashcode()) and then uses the
hashcode as the key instead.
If we're planning on removing HBaseConfiguration entirely, what about
introducing a separate key object that can implement both equals and hashcode
properly based on the relevant information from a Configuration object, then
using that as the key. That would avoid potential collisions, get rid of
having an object with just a hashcode method but not equals, and separate this
connection caching logic away from the Configuration where it doesn't really
belong.
The trick then is identifying the relevant information to base it on. I can
see two ways of doing it, maybe someone else could come up with something
better. The current code uses all properties in the Configuration. This is
complete, but runs the risk of redundant connections for configurations that
have only irrelevant config changes. Another choice would be to explicitly
define the set of hbase config properties that define the connections.
However, this could be fragile to changes.
Anyone else have thoughts?
> Use Configuration instead of HBaseConfiguration
> ------------------------------------------------
>
> Key: HBASE-2036
> URL: https://issues.apache.org/jira/browse/HBASE-2036
> Project: Hadoop HBase
> Issue Type: Improvement
> Reporter: Enis Soztutar
> Attachments: hconf.patch
>
>
> HBaseConfiguration extends Configuration but does not add any functionality
> to it. The only function is hashCode() which really should be refactored into
> Hadoop Configuration.
> I think in all the places(especially in the client side) HBase methods and
> classes should accept Configuration rather than HBaseConfiguration. The
> creation of the configuration with the right files (hbase-site and
> hbase-default) should not be encapsulated in a private method, but in a
> public static one.
> The issues has arisen in our nutch+hbase patch for which we include both
> nutch configuration and hbase configurations. Moreover people may want to
> include separate project-specific configuration files to their configurations
> without the need to be dependent on the HBaseConfiguration.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
