> On Sept. 16, 2015, 9:36 p.m., Bruce Schuchardt wrote: > > Should there really be a default limit on the number of async-close > > threads? Those threads can hang for a while if the machine on the other > > end crashes or there is a network problem. That's why we have > > async-closing in the first place. If the executor fills up with these hung > > threads nothing will be closed until they become unstuck. > > Darrel Schneider wrote: > But if we do have a problem causing close to take a long time do we want > to "try" to create 30,000 threads to close them all? The large number of > thread creations can result in OOM. I did wonder if we are having a problem > with closes blocking for minutes if it might be limited to just a few of our > peers. So perhaps we should have a thread pool dedicated to each other member > instead of just one. What do you think of that idea?
That seems like a good idea - Bruce ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38440/#review99309 ----------------------------------------------------------- On Sept. 16, 2015, 6:32 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, 6:32 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/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 > >
