Wait Flush, Wait Searcher and commit Scenarios

[Grant Ingersoll <gs...@apache.org>]

Was wondering if anyone can fill me in on the when and why I would set  
waitFlush and waitSearcher to false when sending a commit command?  I  
think I understand what they do technically (I've looked at the code),  
but I am not clear about why I would want to do it.  Is there a risk  
in setting them to false? Wouldn't my response return a lot faster if  
it was set to false?  Yet, the default is true for both, so I assume  
there is a reason I want to wait...

Thanks,
Grant

Re: Wait Flush, Wait Searcher and commit Scenarios

[rulinma <ru...@gmail.com>]

good.



--
View this message in context: http://lucene.472066.n3.nabble.com/Wait-Flush-Wait-Searcher-and-commit-Scenarios-tp491509p4131651.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Wait Flush, Wait Searcher and commit Scenarios

[Yonik Seeley <yo...@apache.org>]

On Tue, Nov 18, 2008 at 10:55 PM, Mark Miller <ma...@gmail.com> wrote:
> Does waitFlush do anything now? I only see it being set if eclipse is not
> missing a reference...

Not currently.  The idea was that if waitFlush== false that the call
would be totally asynchronous and return immediately.  If
waitFlush==true, then the call would return only after everything was
flushed to stable storage (which is always the case now).

-Yonik

p.s. late replies since I'm getting back from a week of travel.

Re: Wait Flush, Wait Searcher and commit Scenarios

[Mark Miller <ma...@gmail.com>]

Does waitFlush do anything now? I only see it being set if eclipse is 
not missing a reference...

Ryan McKinley wrote:
> waitFlush I'm not sure...
>
> waitSearcher=true  it will wait until a new searcher is opened after 
> your commit, that way the client is guaranteed to have the results 
> that were just sent in the index.  if waitSearcher=true, a query could 
> hit a searcher that does not have the new documents in the index.
>
>
> On Nov 18, 2008, at 9:13 PM, Grant Ingersoll wrote:
>
>> Was wondering if anyone can fill me in on the when and why I would 
>> set waitFlush and waitSearcher to false when sending a commit 
>> command?  I think I understand what they do technically (I've looked 
>> at the code), but I am not clear about why I would want to do it.  Is 
>> there a risk in setting them to false? Wouldn't my response return a 
>> lot faster if it was set to false?  Yet, the default is true for 
>> both, so I assume there is a reason I want to wait...
>>
>> Thanks,
>> Grant
>

Re: Wait Flush, Wait Searcher and commit Scenarios

[Ryan McKinley <ry...@gmail.com>]

I am using waitSearcher=false with a crawler.  The crawling thread  
finishes a set of stuff, and calls <commit/>.  It does not want to  
search, it gets back to crawling ASAP


On Nov 18, 2008, at 11:35 PM, Grant Ingersoll wrote:

> That explains true, but what about false?  Why would I ever set it  
> to false?  I f I don't wait, how will I ever know when the new  
> searcher is ready?
>
> On Nov 18, 2008, at 10:27 PM, Ryan McKinley wrote:
>
>> waitFlush I'm not sure...
>>
>> waitSearcher=true  it will wait until a new searcher is opened  
>> after your commit, that way the client is guaranteed to have the  
>> results that were just sent in the index.  if waitSearcher=true, a  
>> query could hit a searcher that does not have the new documents in  
>> the index.
>>
>>
>> On Nov 18, 2008, at 9:13 PM, Grant Ingersoll wrote:
>>
>>> Was wondering if anyone can fill me in on the when and why I would  
>>> set waitFlush and waitSearcher to false when sending a commit  
>>> command?  I think I understand what they do technically (I've  
>>> looked at the code), but I am not clear about why I would want to  
>>> do it.  Is there a risk in setting them to false? Wouldn't my  
>>> response return a lot faster if it was set to false?  Yet, the  
>>> default is true for both, so I assume there is a reason I want to  
>>> wait...
>>>
>>> Thanks,
>>> Grant
>>
>
>

Re: Wait Flush, Wait Searcher and commit Scenarios

[Grant Ingersoll <gs...@apache.org>]

That explains true, but what about false?  Why would I ever set it to  
false?  I f I don't wait, how will I ever know when the new searcher  
is ready?

On Nov 18, 2008, at 10:27 PM, Ryan McKinley wrote:

> waitFlush I'm not sure...
>
> waitSearcher=true  it will wait until a new searcher is opened after  
> your commit, that way the client is guaranteed to have the results  
> that were just sent in the index.  if waitSearcher=true, a query  
> could hit a searcher that does not have the new documents in the  
> index.
>
>
> On Nov 18, 2008, at 9:13 PM, Grant Ingersoll wrote:
>
>> Was wondering if anyone can fill me in on the when and why I would  
>> set waitFlush and waitSearcher to false when sending a commit  
>> command?  I think I understand what they do technically (I've  
>> looked at the code), but I am not clear about why I would want to  
>> do it.  Is there a risk in setting them to false? Wouldn't my  
>> response return a lot faster if it was set to false?  Yet, the  
>> default is true for both, so I assume there is a reason I want to  
>> wait...
>>
>> Thanks,
>> Grant
>

Re: Wait Flush, Wait Searcher and commit Scenarios

[Ryan McKinley <ry...@gmail.com>]

waitFlush I'm not sure...

waitSearcher=true  it will wait until a new searcher is opened after  
your commit, that way the client is guaranteed to have the results  
that were just sent in the index.  if waitSearcher=true, a query could  
hit a searcher that does not have the new documents in the index.


On Nov 18, 2008, at 9:13 PM, Grant Ingersoll wrote:

> Was wondering if anyone can fill me in on the when and why I would  
> set waitFlush and waitSearcher to false when sending a commit  
> command?  I think I understand what they do technically (I've looked  
> at the code), but I am not clear about why I would want to do it.   
> Is there a risk in setting them to false? Wouldn't my response  
> return a lot faster if it was set to false?  Yet, the default is  
> true for both, so I assume there is a reason I want to wait...
>
> Thanks,
> Grant