SOLR-5643: ConcurrentUpdateSolrServer will sometimes not spawn a new Runner thread even though there are updates in the queue.

git-svn-id: https://svn.apache.org/repos/asf/lucene/dev/trunk@1559620 13f79535-47bb-0310-9956-ffa450edef68

solr/CHANGES.txt

@@ -210,6 +210,9 @@ Bug Fixes
   distributed searching for some field types such as legacy numeric
   types (Rob Muir, Mike McCandless)
 
+* SOLR-5643: ConcurrentUpdateSolrServer will sometimes not spawn a new Runner
+  thread even though there are updates in the queue. (Mark Miller)
+
 Optimizations
 ----------------------
 

solr/solrj/src/java/org/apache/solr/client/solrj/impl/ConcurrentUpdateSolrServer.java

@@ -255,16 +255,8 @@ public class ConcurrentUpdateSolrServer extends SolrServer {
         }
         handleError(e);
       } finally {
-
-        // remove it from the list of running things unless we are the last
-        // runner and the queue is full...
-        // in which case, the next queue.put() would block and there would be no
-        // runners to handle it.
-        // This case has been further handled by using offer instead of put, and
-        // using a retry loop
-        // to avoid blocking forever (see request()).
         synchronized (runners) {
-          if (runners.size() == 1 && queue.remainingCapacity() == 0) {
+          if (runners.size() == 1 && !queue.isEmpty()) {
             // keep this runner alive
             scheduler.execute(this);
           } else {
@@ -394,6 +386,10 @@ public class ConcurrentUpdateSolrServer extends SolrServer {
           runner.runnerLock.lock();
           runner.runnerLock.unlock();
         } else if (!queue.isEmpty()) {
+          // failsafe - should not be necessary, but a good
+          // precaution to ensure blockUntilFinished guarantees
+          // all updates are emptied from the queue regardless of
+          // any bugs around starting or retaining runners
           Runner r = new Runner();
           runners.add(r);
           scheduler.execute(r);