[
https://issues.apache.org/jira/browse/SOLR-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14999439#comment-14999439
]
Alexandre Rafalovitch commented on SOLR-8272:
---------------------------------------------
A prepare method is a good one. Though I would probably put it in a stack after
QueryComponent, looking at its source it is doing some expanding.
And *prepare* method is run before the actual work is being done, so it is a
good time to reject it with an exception. I assume that stops the flow then and
you don't care how angry you make the client if you stop them from a disallowed
operation.
A quick test would be a custom component just cloning something basic from
SearchComponent implementors:
http://www.solr-start.com/javadoc/solr-lucene/org/apache/solr/handler/component/SearchComponent.html
Then, you put a log statement to dump out the variables in the Request Object.
Perhaps combined with the kind of queries you are trying to stop.
> Allow user to specify actions allowed for each field
> ----------------------------------------------------
>
> Key: SOLR-8272
> URL: https://issues.apache.org/jira/browse/SOLR-8272
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
> Affects Versions: 5.3
> Reporter: Michael Sun
>
> Some actions can be very expensive for some specific fields. For example, in
> my test, a facet query on a text field blow up a few servers in minutes. The
> reason is probably Solr does 'uninversion' on this field for facet which uses
> large amount of field cache. Several Solr servers in turn go into back to
> back full GC cycles and eventually OOM. To prevent scenarios like this, it's
> useful to add an option to allow user to decide if some action is allowed for
> a specific field, particularly for actions using field cache.
> There are two ways to design the switch. It can be either for specific
> action, such as facet, statistic, sorting or for a group of actions, such as
> all actions doing 'uninversion'.
> Some more details about my test. It is a 33-node Solr cluster There is one
> collection on HDFS with 2.6 billion documents in 30 shards.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
