[
https://issues.apache.org/jira/browse/HADOOP-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Kennedy updated HADOOP-1528:
----------------------------------
Description:
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?
was:
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 talbe, 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 minium 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?
> 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
>
> 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.
