Hey Joe, That TPE is used to do batch operations from a single HTable, but those pools cannot be shared the way the code works right now. If you don't need batch operations, you can set hbase.htable.threads.max to 1.
It seems that when you call htable.close it doesn't close the TPE, which is a bug IMO. Can you open a jira? A multi-threaded client should use HTablePool. J-D On Tue, Mar 29, 2011 at 3:49 PM, Joe Pallas <[email protected]> wrote: > Trying to understand why out test program was generating so many threads > (HBase 0.90.0), I discover that every time we instantiate HTable we get a new > thread pool (ThreadPoolExecutor). This seems a bit odd. HTable is not > thread safe, so every thread needs to have its own HTable, but every HTable > creates its own thread pool, and the threads are not shared by the different > HTables. (Isn't that what would make sense if the HTables are on the same > table?) > > Is this the way things are supposed to work? What should I be doing to avoid > creating lots of threads, which seem to hang around for a long time even > though the HTables are discarded. (I'm seeing client GC happen, but threads > don't seem to decrease.) There are some ThreadPoolExecutor parameters that > seem like they could be relevant. > > I found HBASE-3553, which seems related, but only in so far as the fix looks > like it might make this problem worse. > > So: what should a multithreaded client do to be safe and not generate more > threads than are needed? > > Thanks. > joe > >
