slackhappy opened a new pull request #1436: SOLR-14413: allow timeAllowed and cursorMark parameters URL: https://github.com/apache/lucene-solr/pull/1436 # Description [SOLR-14413](https://issues.apache.org/jira/browse/SOLR-14413): allow timeAllowed and cursorMark parameters. 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#L358): ```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); } ``` 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. # Solution Remove the parameter check and assume that the implementer submitting the query accepts the tradeoff between accurate sorting, and timebounded queries. # Tests I removed the corresponding tests that checked the parameter combination - I didn't see any further insight in those tests as to why the combination wasn't allowed, so I assume they were just providing coverage of that check. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [x] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only).
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
