>> So perhaps we should have a thread pool dedicated to each other member instead of just one.
We still have the same issue right? We just moved the problem to peer level pool.... If there is network or machine issues, most likely this will be across all the peers and this may not be helpful... -Anil. On Wed, Sep 16, 2015 at 4:49 PM, Darrel Schneider <[email protected]> wrote: > > > > On Sept. 16, 2015, 2: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? > > > > Bruce Schuchardt wrote: > > That seems like a good idea > > I added this and post an updated review > > > - Darrel > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/38440/#review99309 > ----------------------------------------------------------- > > > 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 > > > > > >
