> On Sept. 17, 2015, 6:33 p.m., Bruce Schuchardt wrote: > > gemfire-core/src/main/java/com/gemstone/gemfire/internal/SocketCreator.java, > > line 1241 > > <https://reviews.apache.org/r/38440/diff/2/?file=1075801#file1075801line1241> > > > > should this use shutdown instead of shutdownNow? Won't shutdownNow > > discard any unexecuted tasks that were just scheduled by the async-closing > > of connections during removeEndpoint processing? > > Darrel Schneider wrote: > Yes, you are correct. My initial concern with shutdown was that it would > block waiting for all those stuck closes to complete. > But both shutdown and shutdownNow do not wait for tasks already scheduled > to finish. You need to call awaitTermination after you called shutdown if you > want to wait for the tasks to complete. With both of these pools we don't > want to wait for termination but we want the thread to go away once all the > tasks that are already scheduled complete. > So I'll change this shutdownNow to shutdown.
with that change I think you're good to go - Bruce ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38440/#review99419 ----------------------------------------------------------- On Sept. 16, 2015, 11:48 p.m., Darrel Schneider wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/38440/ > ----------------------------------------------------------- > > (Updated Sept. 16, 2015, 11:48 p.m.) > > > Review request for geode, Bruce Schuchardt and Kirk Lund. > > > Bugs: GEODE-332 > https://issues.apache.org/jira/browse/GEODE-332 > > > Repository: geode > > > Description > ------- > > The changes in SocketCreator.java are for pooling of async close > (ConnectionTable also calls closeAsyncThreadExecutor). > > The changes in Connection.java and ConnectionTable.java are for pooling of > p2p reader threads. > > The async close thread pool will use at most 32 threads to do socket closes. > Once all 32 threads are busy the unlimited LinkedBlockingQueue starts queuing > close requests. The number of threads can be changed from 32 by using the > "p2p.ASYNC_CLOSE_POOL_MAX_THREADS" system property. > If a thread in this pool is not used for 120 seconds it will timeout (this > timeout can be changed using the "p2p.ASYNC_CLOSE_POOL_KEEP_ALIVE_TIME" > system property). > The threads requesting a socket close will not wait for the close to > complete. The previous code (that created a thread for every request) waited > 50ms for the request to complete. This can be enabled using the > "p2p.ASYNC_CLOSE_WAIT_MILLISECONDS" system property. > > The p2p reader thread pool has an unlimited number of threads. The pool is > used anytime a peer connects to us to create a p2p reader for his sender. It > is also used on the sender side to do the initial handshake when connecting. > If a thread in this pool is not used for 120 seconds it will timeout (this > timeout can be changed using the "p2p.READER_POOL_KEEP_ALIVE_TIME" system > property). > > > Diffs > ----- > > gemfire-core/src/main/java/com/gemstone/gemfire/internal/SocketCreator.java > ff4a22c08f909b731a3a70fa39a893cb5fc0015a > > gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/CacheClientProxy.java > 15f83bb344e453caaad6269ffd63a28f166a02b6 > > gemfire-core/src/main/java/com/gemstone/gemfire/internal/tcp/Connection.java > cd1b7dc998df343a1e035fb9cb68f071073d362c > > gemfire-core/src/main/java/com/gemstone/gemfire/internal/tcp/ConnectionTable.java > 9beb947dfc130634f60022d7385c24e985acab4b > > Diff: https://reviews.apache.org/r/38440/diff/ > > > Testing > ------- > > precheckin > > > Thanks, > > Darrel Schneider > >
