[
https://issues.apache.org/jira/browse/SOLR-9120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244314#comment-16244314
]
Hoss Man commented on SOLR-9120:
--------------------------------
bq. We don't have this warning appearing on version 6.3 though.
You should be able to reproduce these warnings in any situation where:
* you have an instance of Solr 5.5 or newer
* you perform index updates & commits w/o "newSearcher" being opened
* you "concurrently" make requests to the LukeRequestHandler or the
CoreAdminHandler requesting "STATUS" (ie: after the commit, before any
newSearcher)
** these requests can come from the Admin UI passively if it's open in a browser
If you are not seeing these in your 6.3 solr instance, it's probably because
you are not doing any indexing against that instance (you mentioned re-indexing
with the 6.6 and 7.1 "clones" of your original 6.3 instance -- but you didn't
mention anything about running any indexing on the 6.3 instance.
bq. The job will run just fine without having any exceptions and my data in the
index seem to be complete.
correct -- the WARNing messages from LukeRequestHandler come from purely
"informative" code paths that are returning status information about the
current version of the index being searched -- this code path is in no way
involved in anyting indexing related
----
bq. My vote would be "yes": log it only at a DEBUG level and update the message
to something like "Ignoring exception attempting to check (optional) fileSize
stat for: <filename>"
Here's a more concrete straw man proposal that i'll prep a patch for..
* refactor the existing (private) {{getFileLength}} method to be very
specifically named for getting the segments file length (since that's the only
current usage of this method)
* change the semantics of the method so it explicitly attempts to catch
NoSuchFileException and in that case logs it at a DEBUG only level with a very
explicit msg
** something along the lines of "Unable to read the current reader's segments
file length from the index Directory, this can happen if there are new 'on
disk' commits since the reader was opened"
* if any other IOException is caught, continue to log a WARN with a msg that
makes it clear this is being ignored and has not caused any problems for luke
** ie: "Ignoring exception attempting to check (optional) fileSize stat for
segments file"
thoughts?
> o.a.s.h.a.LukeRequestHandler Error getting file length for [segments_NNN] --
> NoSuchFileException
> ------------------------------------------------------------------------------------------------
>
> Key: SOLR-9120
> URL: https://issues.apache.org/jira/browse/SOLR-9120
> Project: Solr
> Issue Type: Bug
> Affects Versions: 6.0
> Reporter: Markus Jelsma
> Attachments: SOLR-9120.patch, SOLR-9120.patch
>
>
> On Solr 6.0, we frequently see the following errors popping up:
> {code}
> java.nio.file.NoSuchFileException:
> /var/lib/solr/logs_shard2_replica1/data/index/segments_2c5
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
> at
> sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
> at
> sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
> at java.nio.file.Files.readAttributes(Files.java:1737)
> at java.nio.file.Files.size(Files.java:2332)
> at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:243)
> at
> org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:131)
> at
> org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:597)
> at
> org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:585)
> at
> org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:137)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2033)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
