[
https://issues.apache.org/jira/browse/SOLR-9120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-9120:
---------------------------
Affects Version/s: 5.5
Description:
Begining with Solr 5.5, the LukeRequestHandler started attempting to report the
name and file size of the segments file for the _current_ Searcher+IndexReader
in use by Solr -- however the filesize information is not always available from
the Directory in cases where "on disk" commits have caused that file to be
removed, for example...
* 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
In situations like this, a decision was made in SOLR-8587 to log a WARNing in
the event that the segments file size could not be determined -- but these
WARNing messages look scary and have lead (many) users to assume something is
wrong with their solr index.
We should reduce the severity of these log messages, and improve the wording to
make it more clear that this is not a fundemental problem with the index.
----
Here's some trivial steps to reproduce the WARN message...
{noformat}
$ bin/solr -e techproducts
...
$ tail -f example/techproducts/logs/solr.log
...
{noformat}
In another terminal...
{noformat}
$ curl -H 'Content-Type: application/json'
'http://localhost:8983/solr/techproducts/update?commit=true&openSearcher=false'
--data-binary '[{"id":"HOSS"}]'
...
$ curl 'http://localhost:8983/solr/techproducts/admin/luke'
...
{noformat}
When the "/admin/luke" URL is hit, this will show up in the logs – but the luke
request will finish correctly...
{noformat}
WARN - 2017-11-08 17:23:44.574; [ x:techproducts]
org.apache.solr.handler.admin.LukeRequestHandler; Error getting file length for
[segments_2]
java.nio.file.NoSuchFileException:
/home/hossman/lucene/dev/solr/example/techproducts/solr/techproducts/data/index/segments_2
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:128)
at
org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:611)
at
org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:584)
at
org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:136)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
...
INFO - 2017-11-08 17:23:44.587; [ x:techproducts]
org.apache.solr.core.SolrCore; [techproducts] webapp=/solr path=/admin/luke
params={} status=0 QTime=15
{noformat}
was:
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}
Issue Type: Improvement (was: Bug)
Summary: LukeRequestHandler logs WARN "Error getting file length
for [segments_NNN]" for inconsequential NoSuchFileException situations -- looks
scary but is not a problem, logging should be reduced (was:
o.a.s.h.a.LukeRequestHandler Error getting file length for [segments_NNN] --
NoSuchFileException)
> LukeRequestHandler logs WARN "Error getting file length for [segments_NNN]"
> for inconsequential NoSuchFileException situations -- looks scary but is not
> a problem, logging should be reduced
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-9120
> URL: https://issues.apache.org/jira/browse/SOLR-9120
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 5.5, 6.0
> Reporter: Markus Jelsma
> Assignee: Hoss Man
> Attachments: SOLR-9120.patch, SOLR-9120.patch, SOLR-9120.patch
>
>
> Begining with Solr 5.5, the LukeRequestHandler started attempting to report
> the name and file size of the segments file for the _current_
> Searcher+IndexReader in use by Solr -- however the filesize information is
> not always available from the Directory in cases where "on disk" commits have
> caused that file to be removed, for example...
> * 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
> In situations like this, a decision was made in SOLR-8587 to log a WARNing in
> the event that the segments file size could not be determined -- but these
> WARNing messages look scary and have lead (many) users to assume something is
> wrong with their solr index.
> We should reduce the severity of these log messages, and improve the wording
> to make it more clear that this is not a fundemental problem with the index.
> ----
> Here's some trivial steps to reproduce the WARN message...
> {noformat}
> $ bin/solr -e techproducts
> ...
> $ tail -f example/techproducts/logs/solr.log
> ...
> {noformat}
> In another terminal...
> {noformat}
> $ curl -H 'Content-Type: application/json'
> 'http://localhost:8983/solr/techproducts/update?commit=true&openSearcher=false'
> --data-binary '[{"id":"HOSS"}]'
> ...
> $ curl 'http://localhost:8983/solr/techproducts/admin/luke'
> ...
> {noformat}
> When the "/admin/luke" URL is hit, this will show up in the logs – but the
> luke request will finish correctly...
> {noformat}
> WARN - 2017-11-08 17:23:44.574; [ x:techproducts]
> org.apache.solr.handler.admin.LukeRequestHandler; Error getting file length
> for [segments_2]
> java.nio.file.NoSuchFileException:
> /home/hossman/lucene/dev/solr/example/techproducts/solr/techproducts/data/index/segments_2
> 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:128)
> at
> org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:611)
> at
> org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:584)
> at
> org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:136)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> ...
> INFO - 2017-11-08 17:23:44.587; [ x:techproducts]
> org.apache.solr.core.SolrCore; [techproducts] webapp=/solr path=/admin/luke
> params={} status=0 QTime=15
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
