[ https://issues.apache.org/jira/browse/SOLR-9330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15513868#comment-15513868 ]
Mike Drob commented on SOLR-9330: --------------------------------- {code} lst.add("searcherName", name); lst.add("caching", cachingEnabled); lst.add("openedAt", openTime); if (registerTime != null) lst.add("registeredAt", registerTime); lst.add("warmupTime", warmupTime); {code} Why not put these in the cached list as well? The first three are final and available before your call to {{snapStatistics}}. The last two are set during {{register}} which should only be called once, if I understand this correctly. Then the whole method becomes {{return readerStats;}} -- much simpler and probably faster too! {code} + // core.getInfoRegistry().remove(STATISTICS_KEY, this); + // decided to comment it, because it might upset users by showing stats, w/o "searcher" entry {code} I don't think there is any reason to keep this in. Other than those minor points, the patch looks good to me. I've had a similar issue when calling {{/replication?command=details}}, but am not able to reproduce it in this test, so I think we're fine to handle that later. > Race condition between core reload and statistics request > --------------------------------------------------------- > > Key: SOLR-9330 > URL: https://issues.apache.org/jira/browse/SOLR-9330 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Affects Versions: 5.5 > Reporter: Andrey Kudryavtsev > Attachments: SOLR-9330.patch, SOLR-9390.patch, SOLR-9390.patch, > SOLR-9390.patch, SOLR-9390.patch, too_sync.patch > > > Things happened that we execute this two requests consecutively in Solr 5.5: > * Core reload: /admin/cores?action=RELOAD&core=_coreName_ > * Check core statistics: /_coreName_/admin/mbeans?stats=true > And sometimes second request ends with this error: > {code} > ERROR org.apache.solr.servlet.HttpSolrCall - > null:org.apache.lucene.store.AlreadyClosedException: this IndexReader is > closed > at org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:274) > at > org.apache.lucene.index.StandardDirectoryReader.getVersion(StandardDirectoryReader.java:331) > at > org.apache.lucene.index.FilterDirectoryReader.getVersion(FilterDirectoryReader.java:119) > at > org.apache.lucene.index.FilterDirectoryReader.getVersion(FilterDirectoryReader.java:119) > at > org.apache.solr.search.SolrIndexSearcher.getStatistics(SolrIndexSearcher.java:2404) > at > org.apache.solr.handler.admin.SolrInfoMBeanHandler.addMBean(SolrInfoMBeanHandler.java:164) > at > org.apache.solr.handler.admin.SolrInfoMBeanHandler.getMBeanInfo(SolrInfoMBeanHandler.java:134) > at > org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:65) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:670) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:458) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:225) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:183) > {code} > If my understanding of SolrCore internals is correct, it happens because of > async nature of reload request: > * New searcher is "registered" in separate thread > * Old searcher is closed in same separate thread and only after new one is > registered > * When old searcher is closing, it removes itself from map with MBeans > * If statistic requests happens before old searcher is completely removed > from everywhere - exception can happen. > What do you think if we will introduce new parameter for reload request which > makes it fully synchronized? Basically it will force it to call {code} > SolrCore#getSearcher(boolean forceNew, boolean returnSearcher, final Future[] > waitSearcher, boolean updateHandlerReopens) {code} with waitSearcher!= null -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org