See https://issues.apache.org/jira/browse/HBASE-3712
On Tue, Mar 29, 2011 at 3:58 PM, Jean-Daniel Cryans <[email protected]>wrote: > Yeah after flushing the remaining edits. > > On Tue, Mar 29, 2011 at 3:56 PM, Ted Yu <[email protected]> wrote: > > Are you suggesting that the thread pool be shutdown in this method ? > > public void close() throws IOException { > > flushCommits(); > > } > > > > > > 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 > >> > >> > > >
