John Gallagher created SOLR-14413:
-------------------------------------

             Summary: allow timeAllowed and cursorMark parameters
                 Key: SOLR-14413
                 URL: https://issues.apache.org/jira/browse/SOLR-14413
             Project: Solr
          Issue Type: Improvement
      Security Level: Public (Default Security Level. Issues are Public)
          Components: search
            Reporter: John Gallagher


Ever since cursorMarks were introduced in SOLR-5463 in 2014, cursorMark and 
timeAllowed parameters were not allowed in combination ("Can not search using 
both cursorMark and timeAllowed")

, from 
[QueryComponent.java|[https://github.com/apache/lucene-solr/blob/03363f413f2134594b012175deb3f10ec9384400/solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java#L359]]:

 
{code:java}
 
 if (null != rb.getCursorMark() && 0 < timeAllowed) {
  // fundamentally incompatible
  throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, "Can not search 
using both " + CursorMarkParams.CURSOR_MARK_PARAM + " and " + 
CommonParams.TIME_ALLOWED);
} {code}
While theoretically impure to use them in combination, it is often desirable to 
support cursormarks-style deep paging and attempt to protect Solr nodes from 
runaway queries using timeAllowed, in the hopes that most of the time, the 
query completes in the allotted time, and there is no conflict.

 

However if the query takes too long, it may be preferable to end the query and 
protect the Solr node and provide the user with a somewhat inaccurate sorted 
list. As noted in SOLR-6930, SOLR-5986 and others, timeAllowed is frequently 
used to prevent runaway load.  In fact, cursorMark and shards.tolerant are 
allowed in combination, so any argument in favor of purity would be a bit 
muddied in my opinion.

 

This was discussed once in the mailing list that I can find: 
[https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201506.mbox/%3c5591740b.4080...@elyograg.org%3E]
 It did not look like there was strong support for preventing the combination.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to