lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: openSearcher, default commit settings
Date Thu, 29 May 2014 17:03:15 GMT
On 5/29/2014 9:21 AM, Boon Low wrote:
> 1. openSearcher (autoCommit)
> According to the Apache Solr reference, "autoCommit/openSearcher" is set to false by
> But on Solr v4.8.1, if "openSearcher" is omitted from the autoCommit config, new searchers
are opened and warmed post auto-commits. Is this behaviour intended or the wiki wrong?

I am reasonably certain that the default for openSearcher if it is not
specified will always be true. My understanding and your actual
experience says that the documentation is wrong.  Additional note: The
docs for autoSoftCommit are basically a footnote on autoCommit, which I
think is a mistake -- it should have its own section, and the docs
should mention that openSearcher does not apply.

I think the code confirms this.  From

  protected UpdateHandlerInfo loadUpdatehandlerInfo() {
    return new UpdateHandlerInfo(get("updateHandler/@class",null),

> 2. openSearcher and other default commit settings
> From previous posts, I know it's not possible to disable commits completely in Solr config
(without coding). But is there a way to configure the default settings of hard/explicit commits
for the update handler? If not it makes sense to have a configuration mechanism. Currently,
a simple commit call seems to be hard-wired with the following options:
> .. commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> There's no server-side option, e.g. to set "openSearcher=false" as default or "invariant"
(cf. searchHandler) to prevent new searchers from opening.
> I found that at times it is necessary to have better server- or infrastructure-side controls
for update/commits, especially in agile teams. Client/UI developers do not necessarily have
complete Solr knowledge. Unintended commits from misbehaving client-side updates may be norm
(e.g. 10 times per minute!).

Since you want to handle commits automatically, you'll want to educate
your developers and tell them that they should never send commits -- let
Solr handle it.  If the code that talks to Solr is Java and uses SolrJ,
you might want to consider using forbidden-apis in your project so that
a build will fail if the commit method gets used.


View raw message