[
https://issues.apache.org/jira/browse/HBASE-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731505#action_12731505
]
Jonathan Gray commented on HBASE-1655:
--------------------------------------
I agree on most of your points... We have an internal HTable pooler (we call it
HBaseRef) that works more like you describe.
- When using byte[] in a HashMap it will actually end up acting on the address
of the byte[] rather than the bytes contained within. You have to use a
wrapping class that would yield hashCode() and equals() methods if you want
byte[] as the key in a HashMap.
- We can switch it all to String, but underneath these are byte[]s so it's just
more consistent to actually use byte[]. If we can keep the API as small as
possible, let's just include both.
- There's no reason we can't do both of these things. Make the constructor
public and you can instantiate them manually. I guess in your framework you
might end up re-instantiating the static map multiple times? The reason I like
it is because you don't have to pass the pool around your code, you can always
just reference the static instance of everything. My vote would be to try to
do both. If we end up
- No worries on the little stuff... all part of the initiation process ;)
Do you think there is a way we could retain the static stuff and still allow
HTablePool to be instantiable? We should just write a nice long class comment
once we settle on the design with the different ways to use it, etc...
I would vote to keep the static stuff as short as possible, maybe just 2 static
methods to get an HTable (w/ and w/o the size param). No statics to get the
HTablePools. You have to instantiate then and that's where you would be able
to set manual HBC and such.
The other thing is to make sure we aren't constructing HBCs constantly.
Good stuff, Ken. Thanks for figuring this.
> Usability improvements to HTablePool
> ------------------------------------
>
> Key: HBASE-1655
> URL: https://issues.apache.org/jira/browse/HBASE-1655
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: client
> Reporter: Ken Weiner
> Assignee: Ken Weiner
> Attachments: HBASE-1655-v2-partial.patch, HBASE-1655.patch
>
>
> A discussion on the HBase user mailing list
> (http://markmail.org/thread/7leeha56ny5mwecg) led to some suggested
> improvements for the org.apache.hadoop.hbase.client.HTablePool class.
> I will be submitting a patch that contains the following changes to
> HTablePool:
> * Remove constructors that were not used.
> * Change access to remaining contstructor from public to private to enforce
> use of the static factory method getPool.
> * Change internal map from TreeMap to HashMap because I couldn't see any
> reason it needed to be sorted.
> * Remove HBaseConfiguration and tableName member variables since they aren't
> really properties of the pool itself. They are associated with the HTable
> that should get instantiated when one is requested from the pool, but not
> already there.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
