-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38440/
-----------------------------------------------------------
(Updated Sept. 18, 2015, 2:43 p.m.)
Review request for geode, Bruce Schuchardt and Kirk Lund.
Changes
-------
Basically added unit tests. But here are some things I discovered from the unit
test:
- changed SocketCloser.close to do shutdown instead of shutdownNow. This will
not cause shutdown to block but does mean that any closes already scheduled
will eventually be attempted.
- Connection now uses an atomic to make sure it only schedules one async close
of its socket.
- When doing a non-async close (because the thread pool has been shutdown) the
code now also runs the optionable "extra" runnable.
- Before we had core threads set to 1 on the pool and an unlimited queue. This
caused us to never have more than one thread. Now core threads is set to max
threads and allowCoreThreadTimeouts is set to true.
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 (updated)
-----
gemfire-core/src/main/java/com/gemstone/gemfire/internal/SocketCloser.java
PRE-CREATION
gemfire-core/src/main/java/com/gemstone/gemfire/internal/SocketCreator.java
ff4a22c08f909b731a3a70fa39a893cb5fc0015a
gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/CacheClientNotifier.java
2cede256f4fd26e46478c459ea5c7ada00161f2f
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
gemfire-core/src/test/java/com/gemstone/gemfire/internal/SocketCloserJUnitTest.java
PRE-CREATION
gemfire-core/src/test/java/com/gemstone/gemfire/internal/SocketCloserWithWaitJUnitTest.java
PRE-CREATION
Diff: https://reviews.apache.org/r/38440/diff/
Testing
-------
precheckin
Thanks,
Darrel Schneider
