> On Sept. 17, 2015, 11:33 a.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?
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. - Darrel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38440/#review99419 ----------------------------------------------------------- On Sept. 16, 2015, 4: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, 4: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 > >
