On 07/01/2011 05:37 PM, Ted Yu wrote:
It would be helpful to file a JIRA. If you can attach a patch, that would be great.
I can do that
BTW Your close() method should call super.close()
PooledHTable does not have a superclass, it simply wraps the HTable so if you call close on it you actually return the table to pool transparently.
Thanks On Fri, Jul 1, 2011 at 7:25 AM, Daniel Iancu<[email protected]> wrote:Hi It look like the usage of HTablePool might be improved. Now, once you get the connection from pool you must take good care to return it by calling HTablePool.putTable(table); If you close the table (say, you don't read carefully the Javadoc) your htable will not be reused. Other case might be if you build a Datasource like object to obtain HTables and, in this case, from the client you don't have a reference to the pool to return the table once done with it. I've fixed all this by subclassing the HTablePool and overriding the getTable method public class HTablePoolEnhanced extends HTablePool @Override public HTableInterface getTable(String tableName) { return new PooledHTable(super.getTable(**tableName)); } where PooledHTable is a inner class that wraps a HTable and reimplements the close method to return the table to pool public class PooledHTable implements HTableInterface { private HTableInterface table; public PooledHTable(HTableInterface table) { this.table = table; } @Override public void close() throws IOException { putTable(table); } ... } } Does it make sense to have this implementation in Hbase also ? It look that all it needs is to have a new HTableInterfaceFactory implementation to create some proxy tables like i did. Regards Daniel
-- Daniel Iancu Java Developer,Web Components Romania 1&1 Internet Development srl. 18 Mircea Eliade St Sect 1, Bucharest RO Bucharest, 012015 www.1and1.ro Phone:+40-031-223-9081
