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

Yonik Seeley commented on SOLR-2809:
------------------------------------

bq. Multiple leases could lead to searchers piling up

It's not so much the number, but how long.
A good default would be perhaps 1 sec... long enough for most individual 
requests to complete, not long enough to cause massive pile-up.

bq. ... perhaps it's less expensive to pass around searcher versions and 
fail+retry distributed requests if the reported version from a node disagrees 
with the version obtained during earlier phases?

That's a good idea, and would have been a nice simple way to do it before NRT 
appeared on the scene ;-)

bq. I guess it depends on the rate of change, and consequently the likelihood 
of failure.

Right.  It would be nice to allow the user to select the trade-off.  For 
example with leases, the user could specify an expensive request (that is 
hopefully run infrequently) that absolutely needs consistency (and fails if it 
can't be achieved.)  The user could specify a longer lease for this request 
(like 60 sec) to ensure that it can normally complete.  This is much nicer than 
saying "requests longer than the NRT commit frequency cannot be guaranteed to 
be correct".

                
> searcher leases
> ---------------
>
>                 Key: SOLR-2809
>                 URL: https://issues.apache.org/jira/browse/SOLR-2809
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Yonik Seeley
>
> Leases/reservations on searcher instances would give us the ability to use 
> the same searcher across phases of a distributed search, or for clients to 
> send multiple requests and have them hit a consistent/unchanging view of the 
> index. The latter requires something extra to ensure that the load balancer 
> contacts the same replicas as before.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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

Reply via email to