I think you need to set that property before you make HBaseConfiguration object. Have you tried that?
On Mon, Mar 13, 2017 at 10:24 AM, Henning Blohm <henning.bl...@zfabrik.de> wrote: > Unfortunately it doesn't seem to make a difference. > > I see that the configuration has hbase.htable.threads.max=1 right before > setting up the Connection but then I still get hundreds of > > hconnection-*** > > threads. Is that actually Zookeeper? > > Thanks, > Henning > > On 13.03.2017 17:28, Ted Yu wrote: > >> Are you using Java client ? >> See the following in HTable : >> >> public static ThreadPoolExecutor getDefaultExecutor(Configuration >> conf) { >> >> int maxThreads = conf.getInt("hbase.htable.threads.max", Integer. >> MAX_VALUE); >> >> FYI >> >> On Mon, Mar 13, 2017 at 9:14 AM, Henning Blohm <henning.bl...@zfabrik.de> >> wrote: >> >> Hi, >>> >>> I am running an HBase client on a very resource limited machine. In >>> particular numproc is limited so that I frequently get "Cannot create >>> native thread" OOMs. I noticed that, in particular in write situations, >>> the >>> hconnection pool grows into the hundreds of threads - even when at most >>> writing with less than ten application threads. Threads are discarded >>> again >>> after some minutes. >>> >>> In conjunction with other programs running on that machine, this >>> sometimes >>> leads to an "overload" situation. >>> >>> Is there a way to keep thread pool usage limited - or in some closer >>> relation with the actual concurrency required? >>> >>> Thanks, >>> >>> Henning >>> >>> >>> >>> > -- Thanks & Regards, Anil Gupta