Major - P3 Our jenkins test detected a hang when shutting down a run of ../bench/wtperf/stress//shared-cache-stress.wtperf, the hang showed a thread was adjusting the pool:
Thread 22 (Thread 0x7f2e0cff9700 (LWP 129430)): #0 0x000000000041b97f in __cache_pool_adjust (session=0x7f2e280174f0, highest=3487, bump_threshold=0, forward=true, adjustedp=0x7f2e0cff8eff) at ../src/conn/conn_cache_pool.c:573 #1 0x000000000041b4c6 in __cache_pool_balance (session=0x7f2e280174f0, forward=true) at ../src/conn/conn_cache_pool.c:446 #2 0x000000000041c035 in __wt_cache_pool_server (arg=0x7f2e280174f0) at ../src/conn/conn_cache_pool.c:758 #3 0x0000003e6ce07555 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003e6cb02ded in clone () from /lib64/libc.so.6
In the debugger it became clear that the in-use proportion of the pool was never being adjusted, so the __cache_pool_balance call was never completing, which meant that destroy could not get the cache pool spin lock and would end up hanging.