lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Drob (JIRA)" <>
Subject [jira] [Commented] (SOLR-9330) Race condition between core reload and statistics request
Date Thu, 22 Sep 2016 17:21:20 GMT


Mike Drob commented on SOLR-9330:

    lst.add("searcherName", name);
    lst.add("caching", cachingEnabled);
    lst.add("openedAt", openTime);
    if (registerTime != null) lst.add("registeredAt", registerTime);
    lst.add("warmupTime", warmupTime);
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!

+    // core.getInfoRegistry().remove(STATISTICS_KEY, this);
+    // decided to comment it, because it might upset users by showing stats, w/o "searcher"
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:
>             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 -
this IndexReader is closed
> 	at org.apache.lucene.index.IndexReader.ensureOpen(
> 	at org.apache.lucene.index.StandardDirectoryReader.getVersion(
> 	at org.apache.lucene.index.FilterDirectoryReader.getVersion(
> 	at org.apache.lucene.index.FilterDirectoryReader.getVersion(
> 	at
> 	at org.apache.solr.handler.admin.SolrInfoMBeanHandler.addMBean(
> 	at org.apache.solr.handler.admin.SolrInfoMBeanHandler.getMBeanInfo(
> 	at org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(
> 	at org.apache.solr.handler.RequestHandlerBase.handleRequest(
> 	at org.apache.solr.core.SolrCore.execute(
> 	at org.apache.solr.servlet.HttpSolrCall.execute(
> 	at
> 	at org.apache.solr.servlet.SolrDispatchFilter.doFilter(
> 	at org.apache.solr.servlet.SolrDispatchFilter.doFilter(
> {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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message