[ https://issues.apache.org/jira/browse/HBASE-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078574#comment-13078574 ]
Ted Yu commented on HBASE-4150: ------------------------------- Looks like we should describe the above scenario in javadoc and book. > Potentially too many connections may be opened if ThreadLocalPool or > RoundRobinPool is used > ------------------------------------------------------------------------------------------- > > Key: HBASE-4150 > URL: https://issues.apache.org/jira/browse/HBASE-4150 > Project: HBase > Issue Type: Bug > Reporter: Ted Yu > Fix For: 0.92.0 > > > See 'Problem with hbase.client.ipc.pool.type=threadlocal in trunk' discussion > started by Lars George. > From Lars Hofhansl: > Looking at HBaseClient.getConnection(...) I see this: > {code} > synchronized (connections) { > connection = connections.get(remoteId); > if (connection == null) { > connection = new Connection(remoteId); > connections.put(remoteId, connection); > } > } > {code} > At the same time PoolMap.ThreadLocalPool.put is defined like this: > {code} > public R put(R resource) { > R previousResource = get(); > if (previousResource == null) { > ... > if (poolSize.intValue() >= maxSize) { > return null; > } > ... > } > {code} > So... If the ThreadLocalPool reaches its capacity it always returns null and > hence all new threads will create a > new connection every time getConnection is called! > I have also verified with a test program that works fine as long as the > number of client threads (which include > the threads in HTable's threadpool of course) is < poolsize. Once that is no > longer the case the number of > connections "explodes" and the program dies with OOMEs (mostly because each > Connection is associated with > yet another thread). > It's not clear what should happen, though. Maybe (1) the ThreadLocalPool > should not have a limit, or maybe > (2) allocations past the pool size should throw an exception (i.e. there's a > hard limit), or maybe (3) in that case > a single connection is returned for all threads while the pool it over its > limit or (4) we start round robin with the other > connection in the other thread locals. > For #1 means that the number of client threads needs to be more carefully > managed by the client app. > In this case it would also be somewhat pointless that Connection have their > own threads, we just pass stuff > between threads. > #2 would work, but puts more logic in the client. > #3 would lead to hard to debug performance issues. > And #4 is messy :) > From Ted Yu: > For HBaseClient, at least the javadoc doesn't match: > {code} > * @param config configuration > * @return either a {@link PoolType#Reusable} or {@link > PoolType#ThreadLocal} > */ > private static PoolType getPoolType(Configuration config) { > return PoolType.valueOf(config.get(HConstants.HBASE_CLIENT_IPC_POOL_TYPE), > PoolType.RoundRobin, PoolType.ThreadLocal); > {code} > I think for RoundRobinPool, we shouldn't allow maxSize to be > Integer#MAX_VALUE. Otherwise connection explosion described by Lars may incur. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira