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 default.
>
> https://cwiki.apache.org/confluence/display/solr/UpdateHandlers+in+SolrConfig
>
> 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 SolrConfig.java:
protected UpdateHandlerInfo loadUpdatehandlerInfo() {
return new UpdateHandlerInfo(get("updateHandler/@class",null),
getInt("updateHandler/autoCommit/maxDocs",-1),
getInt("updateHandler/autoCommit/maxTime",-1),
getBool("updateHandler/autoCommit/openSearcher",true),
getInt("updateHandler/commitIntervalLowerBound",-1),
getInt("updateHandler/autoSoftCommit/maxDocs",-1),
getInt("updateHandler/autoSoftCommit/maxTime",-1),
getBool("updateHandler/commitWithin/softCommit",true));
}
> 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.
https://code.google.com/p/forbidden-apis/
Thanks,
Shawn
