svn commit: r1710592 - /lucene/dev/trunk/solr/core/src/java/org/apache/solr/update/UpdateShardHandler.java

[sh...@apache.org]

Author: shalin
Date: Mon Oct 26 13:15:46 2015
New Revision: 1710592

URL: http://svn.apache.org/viewvc?rev=1710592&view=rev
Log:
Added code comment explaining why this thread pool is unbounded

Modified:
    lucene/dev/trunk/solr/core/src/java/org/apache/solr/update/UpdateShardHandler.java

Modified: lucene/dev/trunk/solr/core/src/java/org/apache/solr/update/UpdateShardHandler.java
URL: http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/update/UpdateShardHandler.java?rev=1710592&r1=1710591&r2=1710592&view=diff
==============================================================================
--- lucene/dev/trunk/solr/core/src/java/org/apache/solr/update/UpdateShardHandler.java (original)
+++ lucene/dev/trunk/solr/core/src/java/org/apache/solr/update/UpdateShardHandler.java Mon Oct 26 13:15:46 2015
@@ -40,7 +40,14 @@ import java.util.concurrent.Executors;
 public class UpdateShardHandler {
   
   private static Logger log = LoggerFactory.getLogger(UpdateShardHandler.class);
-  
+
+  /*
+   * A downside to configuring an upper bound will be big update reorders (when that upper bound is hit)
+   * and then undetected shard inconsistency as a result.
+   * This update executor is used for different things too... both update streams (which may be very long lived)
+   * and control messages (peersync? LIR?) and could lead to starvation if limited.
+   * Therefore this thread pool is left unbounded. See SOLR-8205
+   */
   private ExecutorService updateExecutor = ExecutorUtil.newMDCAwareCachedThreadPool(
       new SolrjNamedThreadFactory("updateExecutor"));