Solr
  1. Solr
  2. SOLR-7587

TestSpellCheckResponse stalled and never timed out -- possible VersionBucket bug? (5.2 branch)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.2, 6.0
    • Component/s: None
    • Labels:
      None

      Description

      On the 5.2 branch (r1681250), I encountered a solrj test stalled for over 110 minutes before i finally killed it...

         [junit4] Suite: org.apache.solr.common.util.TestRetryUtil
         [junit4] Completed [55/60] on J1 in 1.04s, 1 test
         [junit4] 
         [junit4] HEARTBEAT J0 PID(12147@tray): 2015-05-22T18:14:56, stalled for  121s at: TestSpellCheckResponse.testSpellCheckResponse
         [junit4] HEARTBEAT J0 PID(12147@tray): 2015-05-22T18:15:56, stalled for  181s at: TestSpellCheckResponse.testSpellCheckResponse
      ...
         [junit4] HEARTBEAT J0 PID(12147@tray): 2015-05-22T20:00:56, stalled for 6481s at: TestSpellCheckResponse.testSpellCheckResponse
         [junit4] HEARTBEAT J0 PID(12147@tray): 2015-05-22T20:01:56, stalled for 6541s at: TestSpellCheckResponse.testSpellCheckResponse
         [junit4] HEARTBEAT J0 PID(12147@tray): 2015-05-22T20:02:56, stalled for 6601s at: TestSpellCheckResponse.testSpellCheckResponse
      

      I'll attach some jstack output as well as all the temp files from the J0 runner.

      1. jstack.1.txt
        13 kB
        Hoss Man
      2. jstack.2.txt
        13 kB
        Hoss Man
      3. junit4-J0-20150522_181244_599.events
        116 kB
        Hoss Man
      4. junit4-J0-20150522_181244_599.spill
        54 kB
        Hoss Man
      5. junit4-J0-20150522_181244_599.suites
        0.5 kB
        Hoss Man
      6. SOLR-7587_minor_refactor.patch
        1 kB
        Timothy Potter
      7. SOLR-7587.patch
        3 kB
        Timothy Potter

        Issue Links

          Activity

          Hide
          Hoss Man added a comment -

          2 thread dumps, and the non-empty J0 files from solr/build/solr-solrj/test/temp/

          Most interesting looking thread...

          "TEST-TestSpellCheckResponse.testSpellCheckResponse-seed#[FA0A9DF72EDC5BCD]" prio=10 tid=0x00007f10843da000 nid=0x2ff9 waiting on condition [0x00007f10c10f1000]
             java.lang.Thread.State: WAITING (parking)
                  at sun.misc.Unsafe.park(Native Method)
                  - parking to wait for  <0x00000000f7f383e0> (a java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
                  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
                  at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
                  at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
                  at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
                  at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
                  at org.apache.solr.update.VersionInfo.blockUpdates(VersionInfo.java:118)
                  at org.apache.solr.update.UpdateLog.onFirstSearcher(UpdateLog.java:1604)
                  at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1810)
                  at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1505)
                  at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:617)
                  - locked <0x00000000f6f09a10> (a java.lang.Object)
                  at org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:95)
                  at org.apache.solr.update.processor.UpdateRequestProcessor.processCommit(UpdateRequestProcessor.java:64)
                  at org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalCommit(DistributedUpdateProcessor.java:1635)
                  at org.apache.solr.update.processor.DistributedUpdateProcessor.processCommit(DistributedUpdateProcessor.java:1612)
                  at org.apache.solr.update.processor.LogUpdateProcessor.processCommit(LogUpdateProcessorFactory.java:161)
                  at org.apache.solr.handler.RequestHandlerUtils.handleCommit(RequestHandlerUtils.java:69)
                  at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
                  at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
                  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2051)
                  at org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:179)
                  at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
                  at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:483)
                  at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:502)
                  at org.apache.solr.client.solrj.response.TestSpellCheckResponse.testSpellCheckResponse(TestSpellCheckResponse.java:51)
          
          Show
          Hoss Man added a comment - 2 thread dumps, and the non-empty J0 files from solr/build/solr-solrj/test/temp/ Most interesting looking thread... "TEST-TestSpellCheckResponse.testSpellCheckResponse-seed#[FA0A9DF72EDC5BCD]" prio=10 tid=0x00007f10843da000 nid=0x2ff9 waiting on condition [0x00007f10c10f1000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f7f383e0> (a java.util.concurrent.locks.ReentrantReadWriteLock$FairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945) at org.apache.solr.update.VersionInfo.blockUpdates(VersionInfo.java:118) at org.apache.solr.update.UpdateLog.onFirstSearcher(UpdateLog.java:1604) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1810) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1505) at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:617) - locked <0x00000000f6f09a10> (a java.lang.Object) at org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:95) at org.apache.solr.update.processor.UpdateRequestProcessor.processCommit(UpdateRequestProcessor.java:64) at org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalCommit(DistributedUpdateProcessor.java:1635) at org.apache.solr.update.processor.DistributedUpdateProcessor.processCommit(DistributedUpdateProcessor.java:1612) at org.apache.solr.update.processor.LogUpdateProcessor.processCommit(LogUpdateProcessorFactory.java:161) at org.apache.solr.handler.RequestHandlerUtils.handleCommit(RequestHandlerUtils.java:69) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2051) at org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:179) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:483) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:502) at org.apache.solr.client.solrj.response.TestSpellCheckResponse.testSpellCheckResponse(TestSpellCheckResponse.java:51)
          Hide
          Hoss Man added a comment -

          marking as a blocker for 5.2 and assigning to tim to triage.

          (i know tim recently made some VersionBucket chnages in SOLR-7332, so I'm suspicious that this might be related – tim, if i'm wrong, and you're confident this is unrelated, please fill free to unassign and mark non-blocker.)

          Show
          Hoss Man added a comment - marking as a blocker for 5.2 and assigning to tim to triage. (i know tim recently made some VersionBucket chnages in SOLR-7332 , so I'm suspicious that this might be related – tim, if i'm wrong, and you're confident this is unrelated, please fill free to unassign and mark non-blocker.)
          Hide
          Dawid Weiss added a comment -

          Short version of my answer to the list wrt timeout: the default timeout is 120 minutes, so the job was killed before it had a chance to timeout.

          Show
          Dawid Weiss added a comment - Short version of my answer to the list wrt timeout: the default timeout is 120 minutes, so the job was killed before it had a chance to timeout.
          Hide
          Timothy Potter added a comment -

          Hmmm ... I'm not seeing the other thread that the one Hoss pasted in above is blocked on in the thread dumps?

          Anyway, this looks to be related to how EmbeddedSolrServer initializes the SolrCore as the currSearcher should not be null at this point in the test (a commit after a deleteByQuery) ... I would have thought the firstSearcher event (which is what the VersionBucket code hangs off of) would have fired already during core initialization and not at the time of commit.

          Need to step away for today, but will work on it more tomorrow (Sunday) ... seems solvable but I don't want to just hack something in right now. My first thought is to move the call to UpdateLog.onFirstSearcher into the Callable executed by the searcherExecutor, i.e.

          Index: src/java/org/apache/solr/core/SolrCore.java
          ===================================================================
          --- src/java/org/apache/solr/core/SolrCore.java	(revision 1681226)
          +++ src/java/org/apache/solr/core/SolrCore.java	(working copy)
          @@ -1806,14 +1806,15 @@
                   }
           
                   if (currSearcher == null) {
          -          if (updateHandler != null && updateHandler.getUpdateLog() != null) {
          -            updateHandler.getUpdateLog().onFirstSearcher(newSearcher);
          -          }
          -
                     future = searcherExecutor.submit(new Callable() {
                       @Override
                       public Object call() throws Exception {
                         try {
          +
          +                if (updateHandler != null && updateHandler.getUpdateLog() != null) {
          +                  updateHandler.getUpdateLog().onFirstSearcher(newSearcher);
          +                }
          +
                           for (SolrEventListener listener : firstSearcherListeners) {
                             listener.newSearcher(newSearcher, null);
                           }
          

          that would likely address this issue, but when I originally did that, I started seeing a bunch of warnings about multiple on-deck searchers (probably because doing the version bucket lookup takes some time?)

          Show
          Timothy Potter added a comment - Hmmm ... I'm not seeing the other thread that the one Hoss pasted in above is blocked on in the thread dumps? Anyway, this looks to be related to how EmbeddedSolrServer initializes the SolrCore as the currSearcher should not be null at this point in the test (a commit after a deleteByQuery) ... I would have thought the firstSearcher event (which is what the VersionBucket code hangs off of) would have fired already during core initialization and not at the time of commit. Need to step away for today, but will work on it more tomorrow (Sunday) ... seems solvable but I don't want to just hack something in right now. My first thought is to move the call to UpdateLog.onFirstSearcher into the Callable executed by the searcherExecutor, i.e. Index: src/java/org/apache/solr/core/SolrCore.java =================================================================== --- src/java/org/apache/solr/core/SolrCore.java (revision 1681226) +++ src/java/org/apache/solr/core/SolrCore.java (working copy) @@ -1806,14 +1806,15 @@ } if (currSearcher == null ) { - if (updateHandler != null && updateHandler.getUpdateLog() != null ) { - updateHandler.getUpdateLog().onFirstSearcher(newSearcher); - } - future = searcherExecutor.submit( new Callable() { @Override public Object call() throws Exception { try { + + if (updateHandler != null && updateHandler.getUpdateLog() != null ) { + updateHandler.getUpdateLog().onFirstSearcher(newSearcher); + } + for (SolrEventListener listener : firstSearcherListeners) { listener.newSearcher(newSearcher, null ); } that would likely address this issue, but when I originally did that, I started seeing a bunch of warnings about multiple on-deck searchers (probably because doing the version bucket lookup takes some time?)
          Hide
          Timothy Potter added a comment -

          This is actually happening for other tests too, so isn't related to EmbeddedSolrServer, see:
          http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4724/

          Show
          Timothy Potter added a comment - This is actually happening for other tests too, so isn't related to EmbeddedSolrServer, see: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4724/
          Hide
          ASF subversion and git services added a comment -

          Commit 1681486 from Timothy Potter in branch 'dev/trunk'
          [ https://svn.apache.org/r1681486 ]

          SOLR-7587: First attempt at fixing the dead-lock; moved call to UpdateLog.onFirstSearcher to end of the SolrCore constructor as it only needs to run once per core initialization

          Show
          ASF subversion and git services added a comment - Commit 1681486 from Timothy Potter in branch 'dev/trunk' [ https://svn.apache.org/r1681486 ] SOLR-7587 : First attempt at fixing the dead-lock; moved call to UpdateLog.onFirstSearcher to end of the SolrCore constructor as it only needs to run once per core initialization
          Hide
          ASF subversion and git services added a comment -

          Commit 1681487 from Timothy Potter in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1681487 ]

          SOLR-7587: First attempt at fixing the dead-lock; moved call to UpdateLog.onFirstSearcher to end of the SolrCore constructor as it only needs to run once per core initialization

          Show
          ASF subversion and git services added a comment - Commit 1681487 from Timothy Potter in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1681487 ] SOLR-7587 : First attempt at fixing the dead-lock; moved call to UpdateLog.onFirstSearcher to end of the SolrCore constructor as it only needs to run once per core initialization
          Hide
          ASF subversion and git services added a comment -

          Commit 1681489 from Timothy Potter in branch 'dev/branches/lucene_solr_5_2'
          [ https://svn.apache.org/r1681489 ]

          SOLR-7587: First attempt at fixing the dead-lock; moved call to UpdateLog.onFirstSearcher to end of the SolrCore constructor as it only needs to run once per core initialization

          Show
          ASF subversion and git services added a comment - Commit 1681489 from Timothy Potter in branch 'dev/branches/lucene_solr_5_2' [ https://svn.apache.org/r1681489 ] SOLR-7587 : First attempt at fixing the dead-lock; moved call to UpdateLog.onFirstSearcher to end of the SolrCore constructor as it only needs to run once per core initialization
          Hide
          Timothy Potter added a comment -

          Just a heads up on this ... I had to commit a possible fix as I haven't been able to reproduce the hangs locally. The fix moves the call to UpdateLog.onFirstSearcher to the end of the SolrCore ctor as it only needs to run once per core initialization.

          Show
          Timothy Potter added a comment - Just a heads up on this ... I had to commit a possible fix as I haven't been able to reproduce the hangs locally. The fix moves the call to UpdateLog.onFirstSearcher to the end of the SolrCore ctor as it only needs to run once per core initialization.
          Hide
          Timothy Potter added a comment -

          Here's a patch that shows the code I committed

          Show
          Timothy Potter added a comment - Here's a patch that shows the code I committed
          Hide
          Timothy Potter added a comment -

          Have a little more information about what caused this failure. Had to dig into the JavaDoc for ReentrantReadWriteLock a bit and found this little gem:

          Reentrancy also allows downgrading from the write lock to a read lock, by acquiring the write lock, then the read lock and then releasing the write lock. However, upgrading from a read lock to the write lock is not possible.

          All the test failures because of this situation occurred during a commit. Commits acquire a read-lock on the VersionInfo object (see DistributedUpdateProcessor#versionAdd method). My code introduced the need for acquiring the write-lock and as we learned above, you can't upgrade a read-lock to a write-lock. The problem is where I had this code; specifically I hung it off of the code that handles firstSearcher events, since I need a searcher in order to lookup the max value from the index to seed version buckets with. But all this seems like the test should fail consistently every time, which is not the case. So clearly there's some timing involved with this fail. This code only fires when currSearcher == null and I don't get how that could be at the point where the test is sending a commit (see below)?

                  at org.apache.solr.update.VersionInfo.blockUpdates(VersionInfo.java:118)
                  at org.apache.solr.update.UpdateLog.onFirstSearcher(UpdateLog.java:1604)
                  at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1810)
                  at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1505)
                  at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:617)
                  - locked <0x00000000f6f09a10> (a java.lang.Object)
                  at org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:95)
                  at org.apache.solr.update.processor.UpdateRequestProcessor.processCommit(UpdateRequestProcessor.java:64)
                  at org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalCommit(DistributedUpdateProcessor.java:1635)
                  at org.apache.solr.update.processor.DistributedUpdateProcessor.processCommit(DistributedUpdateProcessor.java:1612)
                  at org.apache.solr.update.processor.LogUpdateProcessor.processCommit(LogUpdateProcessorFactory.java:161)
                  at org.apache.solr.handler.RequestHandlerUtils.handleCommit(RequestHandlerUtils.java:69)
                  at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
                  at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
                  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2051)
                  at org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:179)
                  at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
                  at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:483)
                  at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:502)
                  at org.apache.solr.client.solrj.response.TestSpellCheckResponse.testSpellCheckResponse(TestSpellCheckResponse.java:51)
          

          The searcher gets registered in futures but seems unlikely that the test should get this far before the searcher opened during core initialization is set to the currSearcher. At any rate, the patch I submitted moves the bucket seeding code (which needs a write-lock) out of the firstSearcher code path and into the SolrCore ctor, which fixes the issue of needing a write-lock when a read-lock as already been acquired for a commit operation. It's still a question in my mind as to how the test can get to sending a commit when currSearcher == null ... any thoughts on that?

          Show
          Timothy Potter added a comment - Have a little more information about what caused this failure. Had to dig into the JavaDoc for ReentrantReadWriteLock a bit and found this little gem: Reentrancy also allows downgrading from the write lock to a read lock, by acquiring the write lock, then the read lock and then releasing the write lock. However, upgrading from a read lock to the write lock is not possible. All the test failures because of this situation occurred during a commit. Commits acquire a read-lock on the VersionInfo object (see DistributedUpdateProcessor#versionAdd method). My code introduced the need for acquiring the write-lock and as we learned above, you can't upgrade a read-lock to a write-lock. The problem is where I had this code; specifically I hung it off of the code that handles firstSearcher events, since I need a searcher in order to lookup the max value from the index to seed version buckets with. But all this seems like the test should fail consistently every time, which is not the case. So clearly there's some timing involved with this fail. This code only fires when currSearcher == null and I don't get how that could be at the point where the test is sending a commit (see below)? at org.apache.solr.update.VersionInfo.blockUpdates(VersionInfo.java:118) at org.apache.solr.update.UpdateLog.onFirstSearcher(UpdateLog.java:1604) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1810) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1505) at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:617) - locked <0x00000000f6f09a10> (a java.lang. Object ) at org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:95) at org.apache.solr.update.processor.UpdateRequestProcessor.processCommit(UpdateRequestProcessor.java:64) at org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalCommit(DistributedUpdateProcessor.java:1635) at org.apache.solr.update.processor.DistributedUpdateProcessor.processCommit(DistributedUpdateProcessor.java:1612) at org.apache.solr.update.processor.LogUpdateProcessor.processCommit(LogUpdateProcessorFactory.java:161) at org.apache.solr.handler.RequestHandlerUtils.handleCommit(RequestHandlerUtils.java:69) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2051) at org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:179) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:483) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:502) at org.apache.solr.client.solrj.response.TestSpellCheckResponse.testSpellCheckResponse(TestSpellCheckResponse.java:51) The searcher gets registered in futures but seems unlikely that the test should get this far before the searcher opened during core initialization is set to the currSearcher. At any rate, the patch I submitted moves the bucket seeding code (which needs a write-lock) out of the firstSearcher code path and into the SolrCore ctor, which fixes the issue of needing a write-lock when a read-lock as already been acquired for a commit operation. It's still a question in my mind as to how the test can get to sending a commit when currSearcher == null ... any thoughts on that?
          Hide
          Timothy Potter added a comment -

          I chose to move the seed bucket version code before the call to bufferUpdatesIfConstructing during SolrCore construction ... also note that since the previous patch has already been committed, this is in addition to that.

          Show
          Timothy Potter added a comment - I chose to move the seed bucket version code before the call to bufferUpdatesIfConstructing during SolrCore construction ... also note that since the previous patch has already been committed, this is in addition to that.
          Hide
          Anshum Gupta added a comment -

          Timothy Potter : Is this still a blocker?

          Show
          Anshum Gupta added a comment - Timothy Potter : Is this still a blocker?
          Hide
          ASF subversion and git services added a comment -

          Commit 1682016 from Timothy Potter in branch 'dev/trunk'
          [ https://svn.apache.org/r1682016 ]

          SOLR-7587: Move the call to seed version buckets to before buffering updates during core construction

          Show
          ASF subversion and git services added a comment - Commit 1682016 from Timothy Potter in branch 'dev/trunk' [ https://svn.apache.org/r1682016 ] SOLR-7587 : Move the call to seed version buckets to before buffering updates during core construction
          Hide
          ASF subversion and git services added a comment -

          Commit 1682017 from Timothy Potter in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1682017 ]

          SOLR-7587: Move the call to seed version buckets to before buffering updates during core construction

          Show
          ASF subversion and git services added a comment - Commit 1682017 from Timothy Potter in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1682017 ] SOLR-7587 : Move the call to seed version buckets to before buffering updates during core construction
          Hide
          ASF subversion and git services added a comment -

          Commit 1682019 from Timothy Potter in branch 'dev/branches/lucene_solr_5_2'
          [ https://svn.apache.org/r1682019 ]

          SOLR-7587: Move the call to seed version buckets to before buffering updates during core construction

          Show
          ASF subversion and git services added a comment - Commit 1682019 from Timothy Potter in branch 'dev/branches/lucene_solr_5_2' [ https://svn.apache.org/r1682019 ] SOLR-7587 : Move the call to seed version buckets to before buffering updates during core construction
          Hide
          Anshum Gupta added a comment -

          Bulk close for 5.2.0.

          Show
          Anshum Gupta added a comment - Bulk close for 5.2.0.

            People

            • Assignee:
              Timothy Potter
              Reporter:
              Hoss Man
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development