Taking another look at this one. The distributed update and search requests are the most frequent users of this executor. Tracing each, I see that the Runnable added by HttpShardHandler.submit, SolrCmdDistributor.submit and StreamingSolrClients.ErrorReportingConcurrentUpdateSolrClient never throw any exceptions but they are tracked and logged as part of the shard response or similar classes. Therefore there is no point in creating an Exception object for these two usages. So, this patches adds another constructor for MDCAwareThreadPoolExecutor which disables the submitter stack trace for search and update use-cases.
If we remove that exception then we're running blind. There would be no way to get the stack trace of the submitter when an actual exception happens inside the executor thread.