Page History

There are a number of thread pool factory methods in CoreLoggingExecutors (each static method returns an ExecutorService.) A number of them construct a new PooledExecutorWithDMStats:

• newThreadPoolWithSynchronousFeed(int poolSize, String threadName, CommandWrapper commandWrapper)
  
  used by AcceptorImpl in org.apache.geode.internal.cache.tier.sockets

  
  

• newThreadPoolWithSynchronousFeed(int poolSize, long keepAliveTime, TimeUnit unit, String threadName, CommandWrapper commandWrapper, PoolStatHelper poolStatHelper, ThreadsMonitoring threadsMonitoring)

used by ExpiryTask in org.apache.geode.internal.cache
  
  

• newThreadPoolWithFixedFeed(int poolSize, long keepAliveTime, TimeUnit unit, int workQueueSize, String threadName, CommandWrapper commandWrapper, PoolStatHelper poolStatHelper, ThreadsMonitoring threadsMonitoring)

used by GemFireCacheImpl in org.apache.geode.internal.cache
  
  

• newThreadPoolWithUnlimitedFeed(int poolSize, long keepAliveTime, TimeUnit unit, String threadName, ThreadInitializer threadInitializer, CommandWrapper commandWrapper, PoolStatHelper poolStatHelper, ThreadsMonitoring threadsMonitoring)
  
  used by AcceptorImpl in org.apache.geode.internal.cache.tier.sockets

• 
  

• newThreadPool(int poolSize, BlockingQueue<Runnable> workQueue,String threadName, ThreadInitializer threadInitializer, CommandWrapper commandWrapper, PoolStatHelper poolStatHelper, ThreadsMonitoring threadsMonitoring)

used by ClusterOperationExecutors in org.apache.geode.distributed.internal

Each of those constructs a new PooledExecutorWithDMStats. Here's how that thing is structured…

PooledExecutorWithDMStats has (in general) 2 queues and a rejected execution handler:

...

Darrel Schneider thinks maybe this code also has something to do with core threads and wanting to get all the threads busy before we start buffering requests up in a queue. I think As he recalls, we saw that if we used a non-sync-queue to feed the executor, then it would end up doing all the work in a single thread. Here is one discussion that touches on this issue: https://stackoverflow.com/questions/47650247/synchronousqueue-in-threadpoolexecutor

But this code in AdoptOpenJDK 8 ThreadPoolExecutor.execute() looks like it would perform just fine if the workQueue was a non-synchronous queue:

Perhaps a quick test is needed here to confirm Darrel Schneider's recollection…