3

I have a vanilla Sitecore 10.1 SXA setup on Docker. And for all intents and purposes it functions fine.

However. Sometimes, and I've not been able to track down when or why this happens exactly, Solr "falls over" and starts giving the below exception when I try to rebuild indexes. Once this state is reached, nothing I do seems to be able to bring it back to life.

The only "fix" I've found at this stage is taking down the containers, deleting /data/solr and bringing the containers back up again (forcing the internal initialization). Once done I can populate the schema again, rebuild the indexes, and everything is fine. Until it falls over again for some unknown reason.

I am not deploying anything custom to Solr, in fact I do nothing to Solr at all. It just falls over.

Here's the exception:

Job started: Index_Update_IndexName=sitecore_core_index|#Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> SolrNet.Exceptions.SolrConnectionException: <?xml version="1.0" encoding="UTF-8"?>
<response>

<lst name="responseHeader">
  <int name="status">500</int>
  <int name="QTime">21</int>
</lst>
<lst name="error">
  <str name="msg">C:\data\sitecore_core_index_shard1_replica_n1\data\index\pending_segments_6 -&gt; C:\data\sitecore_core_index_shard1_replica_n1\data\index\segments_6</str>
  <str name="trace">java.nio.file.NoSuchFileException: C:\data\sitecore_core_index_shard1_replica_n1\data\index\pending_segments_6 -&gt; C:\data\sitecore_core_index_shard1_replica_n1\data\index\segments_6
    at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79)
    at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
    at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:301)
    at sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
    at java.nio.file.Files.move(Files.java:1395)
    at org.apache.lucene.store.FSDirectory.rename(FSDirectory.java:302)
    at org.apache.lucene.store.NRTCachingDirectory.rename(NRTCachingDirectory.java:167)
    at org.apache.lucene.store.LockValidatingDirectoryWrapper.rename(LockValidatingDirectoryWrapper.java:56)
    at org.apache.lucene.index.SegmentInfos.finishCommit(SegmentInfos.java:797)
    at org.apache.lucene.index.IndexWriter.finishCommit(IndexWriter.java:3486)
    at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3453)
    at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3410)
    at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:678)
    at org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:102)
    at org.apache.solr.update.processor.UpdateRequestProcessor.processCommit(UpdateRequestProcessor.java:68)
    at org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalCommit(DistributedUpdateProcessor.java:1079)
    at org.apache.solr.update.processor.DistributedZkUpdateProcessor.processCommit(DistributedZkUpdateProcessor.java:220)
    at org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processCommit(LogUpdateProcessorFactory.java:160)
    at org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:281)
    at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:188)
    at org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
    at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
    at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211)
    at org.apache.solr.core.SolrCore.execute(SolrCore.java:2596)
    at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:799)
    at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:578)
    at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:419)
    at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351)
    at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
    at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
    at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
    at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
    at org.eclipse.jetty.server.Server.handle(Server.java:505)
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)
    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
    at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
    at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
    at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917)
    at java.lang.Thread.run(Thread.java:748)
</str>
  <int name="code">500</int>
</lst>
</response>

Looking at the Solr logs, this is what I see.


Time (Local)    Level   Core    Logger  Message
5/18/2021, 8:45:06 AM
WARN false
SolrResourceLoader
Solr loaded a deprecated plugin/analysis class [solr.SynonymFilterFactory]. Please consult documentation how to replace it accordingly.
5/18/2021, 8:45:23 AM
WARN false
x:sitecore_core_index_shard1_replica_n1
UpdateLog
Starting log replay tlog{file=c:\data\sitecore_core_index_shard1_replica_n1\data\tlog\tlog.0000000000000000006 refcount=2} active=false starting pos=0 inSortedOrder=false
5/18/2021, 8:45:23 AM
ERROR false
x:sitecore_core_index_shard1_replica_n1
UpdateLog
Replay exception: final commit.
Improve this question

1 Answer 1

Reset to default
4

I don't know what's the original reason of that error but that's a long known issue with Sitecore and Solr and Docker.

You can read a thread here https://github.com/Sitecore/docker-images/issues/182 . It started in Dec 2019 and issue is still not fixed in Jan 2021.

Is there any solution? It's not really solution but workaround: change isolation level from process to hyperv for the solr service (at minimum).

So either update your .env file:

ISOLATION=hyperv

Alternatively set the solr service to run in hyperv in the docker-compose.yml or docker-compose.override.yml file.

solr:
    isolation: hyperv
    image: ${SITECORE_DOCKER_REGISTRY}nonproduction/solr:8.4.0-${SITECORE_VERSION}
    ports:
      - "8984:8983"
    volumes:
      - type: bind
        source: .\solr-data
        target: c:\data
    environment:
      SOLR_MODE: solrcloud
Improve this answer
1
  • For the record, I am on Windows 10 20H2. I took my containers down, made the configuration change, and brought the containers back up. I could immediately rebuild my indexes after that, without needing to first clean the data folders.
    – Mark Cassidy
    May 18, 2021 at 7:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.