[
https://issues.apache.org/jira/browse/SOLR-15252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17322544#comment-17322544
]
Jan Høydahl commented on SOLR-15252:
------------------------------------
You propose that we set 10k as default maxRows and fail the request if
exceeded? And then make it configurable so people must actively lift it if they
have a use case for it?
It's a more brutal and visible approach that requires quite much more code and
documentation. I feel it is enough with just a log warning, but configurable.
This is somewhat different from maxBooleanClauses, since user-provided queries
could blow up and cause issues. In this case, the client app developer will
decide what rows counts to use and is typically something that is quite static
per application, not per-query.
Interested to hear from others.
> Solr should log WARN log when a query requests huge rows number
> ---------------------------------------------------------------
>
> Key: SOLR-15252
> URL: https://issues.apache.org/jira/browse/SOLR-15252
> Project: Solr
> Issue Type: Improvement
> Components: query
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have all seen it - clients that use Integer.MAX_VALUE or 10000000 as rows
> parameter, to just make sure they get all possible results. And this of
> course leads to high GC pauses since Lucene allocates an array up front to
> hold results.
> Solr should either log WARN when it encounters a value above a certain
> threshold, such as 100k (then you should use cursormark instead). Or it
> should simply respond with 400 error and have a system property or query
> parameter folks can use to override if they know what they are doing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
