[
https://issues.apache.org/jira/browse/SOLR-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736910#comment-15736910
]
Hoss Man commented on SOLR-9841:
--------------------------------
bq. Well, that's not the original issue, is it? The problem is that we're
opening multiple searchers in rapid succession apparently due to autocommit
expiry coupled with this commit. ...
I've seen no indication/confirmation of that -- the original mail thread that
spawned this issue noted only that multiple on deck searchers as the result of
using the doc expiration processor with a autoDeletePeriodSeconds=30 -- if
warming takes more then 30 seconds *AND* docs are expiring at a frequency of at
least 30 seconds, then that would explaining the multiple on deck searchers,
even if there were no other adds/commits.
bq. ... maybe I'm jumping the gun here and the real question is whether the
commit from the code resets the autocommit expiry?
All commits reset the autocommit timmer, regardless of when/why it was started.
bq. We can quibble about this one I suppose. In many cases it's probably good
enough to let the next autocommit take care of opening a new searcher and
rendering the docs un-findable rather than forcing the commit from the code.
This assumes that the delete-by-query starts an autocommit timer.
I suppose the processor could try to detect if autocommit is enabled, and only
use commitWithin on the delete instead of triggering the softCommit directly?
... but i really think adding yet another config option that people might get
wrong (ie: if they aren't using autoCommit) is a bad idea.
the bottom line is: if the processor is triggering on deck warming warnings
when configured to run every 30 seconds, then even if it didn't trigger commits
directly there would still be on deck warming warnings if the autoCommit is <=
30 seconds.
> Disable expiration processor commits
> ------------------------------------
>
> Key: SOLR-9841
> URL: https://issues.apache.org/jira/browse/SOLR-9841
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Reporter: Brent Pearson
>
> http://lucene.472066.n3.nabble.com/Adding-DocExpirationUpdateProcessorFactory-causes-quot-Overlapping-onDeckSearchers-quot-warnings-td4309155.html
> Need a way to have document expiration update processor *not* trigger
> additional commits.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
