[ 
https://issues.apache.org/jira/browse/SOLR-7133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14331981#comment-14331981
 ] 

Shawn Heisey commented on SOLR-7133:
------------------------------------

The default value of openSearcher on a hard commit is *already* true.  In order 
to make it false, it must be explicitly set to false.  This default was 
established so that people who were used to the way that Solr 1.x and 3.x 
(which did not have the openSearcher parameter) behaved on a commit would not 
suddenly have new behavior when they performed the same action on Solr 4.x.  
Soft commits and the transaction log are new features in 4.x.  Those new 
features required the addition of the openSearcher feature.

The openSearcher value controls whether or not a new searcher will be opened 
when the commit finishes -- whether any changes to the index will be visible or 
not.  Did you read the URL about understanding transaction logs, hard commits, 
and soft commits?  That article discusses openSearcher.

http://lucidworks.com/blog/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/
https://issues.apache.org/jira/browse/SOLR-3069


> Solr is required to be restarted after updating with flume
> ----------------------------------------------------------
>
>                 Key: SOLR-7133
>                 URL: https://issues.apache.org/jira/browse/SOLR-7133
>             Project: Solr
>          Issue Type: Bug
>          Components: Data-driven Schema
>    Affects Versions: 4.10.3
>         Environment: Oracle Linux 6.6
> solr 4.10.3
> flume-1.4.0
>            Reporter: DeepakVohra
>
> After updating Solr with Flume the Solr is required to be restarted before 
> the updates get listed with /select query. Shouldn't the updates get listed 
> with /select query without restarting Solr as with updating from the Solr 
> Admin Console?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to