hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashish Shinde <ash...@strandls.com>
Subject Re: Is HTable threadsafe and cachable?
Date Mon, 04 Apr 2011 11:12:54 GMT
Hi Ryan,

Thanks HTablePool fits the bill. Will start using it. 

I kinda discovered the re-use of Configuration object after zookeeper
"too many connections" errors. Although I could not find it documented
anywhere. Had to dig into HTable code to figure it out.

Thanks and regards,
- Ashish



On Mon, 4 Apr 2011 00:50:34 -0700
Ryan Rawson <ryanobjc@gmail.com> wrote:

> Hey,
> 
> HTable instances are not really thread safe at this time.  You can
> cache them, check out HTablePool.  But the creation cost of a HTable
> instance isnt that high, the actual TCP socket creation and management
> is done at a lower level and all HTable interfaces share these common
> caches and sockets. So you can create a number of HTable instances
> without creating a large number of sockets.
> 
> Oh and be sure to re-use the same Configuration object, or else you'll
> end up with multiple sockets.  This is because we use the Config
> object to know when two HTables are accessing the same cluster.
> 
> -ryan
> 
> On Mon, Apr 4, 2011 at 12:45 AM, Ashish Shinde <ashish@strandls.com>
> wrote:
> > Hi,
> >
> > We are using hbase to power a web application. The current
> > implementation of the data access classes maintain a static HTable
> > instance to read and write. The reason being getting hold of HTable
> > instance looks costly.
> >
> > In this scenario the HTable instances could more or less be
> > perpetually cached. Is it reasonable to assume that HTables do not
> > have some inherent timeout and are threadsafe across gets and puts?
> >
> > Thanks and regards,
> > - Ashish
> >
> >
> >


Mime
View raw message