[
https://issues.apache.org/jira/browse/HADOOP-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Kennedy updated HADOOP-1528:
----------------------------------
Attachment: HConnection.patch
Submitted a patch with four new files:
HConnection
HTable
TableNotFoundException
TestHConnection
and additions of equals() and hashcode() to Configuration.
Assuming you guys like this code:
I'm not sure what the best way to integrate this would be. HConnection and
HTable repeat a lot of the same code that is in HClient. Should we maintain
them separately? If we replace HClient we'll need to refactor a lot of places
where it is used. If that's the way to go, I would suggest modifiying HClient
to be a facade for HConnection/HTable to ditch the repeated code. Deprecate it
and then slowly replace it with HConnection wherever we see it.
> HClient for multiple tables
> ---------------------------
>
> Key: HADOOP-1528
> URL: https://issues.apache.org/jira/browse/HADOOP-1528
> Project: Hadoop
> Issue Type: Task
> Components: contrib/hbase
> Affects Versions: 0.14.0
> Reporter: James Kennedy
> Attachments: HConnection.patch
>
>
> I have an app that needs to access multiple HBase tables concurrently. The
> current HClient can only have one table open at a time even though it caches
> region servers of multiple tables as they are looked up.
> This means that my application layer must open multiple HClients, one per
> table, perhaps caching those HClients in a pool to reuse them (and their
> cached table data) as appropriate.
> or
> Shall I write an HClient patch that makes the HClient multi-table
> thread-safe?
> Jim's suggestion is to implement an HClient singleton (call it
> HClientManager?) that does the actual caching/resync of root/meta regions.
> Individual HClients will still be one table, one update row at a time but
> will rely on the singleton for the cached table info. We want HClients to be
> created and disposed as fast as possible with a minimum of meta lookups.
> Jim, what about non-root/meta regions, shouldn't they be cached and refreshed
> via the singleton also? It may still be possible that a region split/resync
> will occur during on HClient session so does the HClientManager need to be
> able to notify the corresponding HClients in that event?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.