[
https://issues.apache.org/jira/browse/SOLR-14413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17220001#comment-17220001
]
John Gallagher commented on SOLR-14413:
---------------------------------------
[~bvd] the issue was with an assumption that the test was making.
It is not always true that every document will be found when using timeAllowed
and cursorMark in combination. There may be holes in the result sets, but at
least the ordering between and within result sets will be correct with respect
to the sort.
This is what I had suspected was the case when I proposed allowing the
combination, but I didn't have an example at the time. I think it is still a
good idea to allow these parameters in combination (its something that you
could encounter when using shards.tolerant and cursorMark in combination, and
that combination is allowed).
When using timeAllowed and cursorMark in combination, and there are multiple
segments in the index, it is possible that a query may terminate before
visiting the matching documents in every segment. The hint for this is in the
warning message's stack trace associated with the failing seed you found in the
previous revision:
[https://gist.github.com/slackhappy/1a48d56e10679404cea3441f87a0fecc#file-gistfile1-txt-L6]
. "The request took too long to iterate over terms." occurs while in a
specific segment, which prevents iterating on to the next segment.
I have updated my pull request:
[https://github.com/apache/lucene-solr/pull/1436]
And I have updated my proposed documentation changes to include a mention that
results may be missing if partialResults is true:
!Screen Shot 2020-10-23 at 10.08.26 PM.png|width=545,height=114!
!Screen Shot 2020-10-23 at 10.09.11 PM.png|width=577,height=161!
> allow timeAllowed and cursorMark parameters
> -------------------------------------------
>
> Key: SOLR-14413
> URL: https://issues.apache.org/jira/browse/SOLR-14413
> Project: Solr
> Issue Type: Improvement
> Components: search
> Reporter: John Gallagher
> Priority: Minor
> Attachments: SOLR-14413-bram.patch, SOLR-14413-jg-update1.patch,
> SOLR-14413-jg-update2.patch, SOLR-14413.patch, Screen Shot 2020-10-23 at
> 10.08.26 PM.png, Screen Shot 2020-10-23 at 10.09.11 PM.png,
> image-2020-08-18-16-56-41-736.png, image-2020-08-18-16-56-59-178.png,
> image-2020-08-21-14-18-36-229.png, timeallowed_cursormarks_results.txt
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> 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|#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.
>
> I have tested cursorMark and timeAllowed combination together, and even when
> partial results are returned because the timeAllowed is exceeded, the
> cursorMark response value is still valid and reasonable.
--
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
