[ 
https://issues.apache.org/jira/browse/SOLR-13529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859604#comment-16859604
 ] 

Anshum Gupta commented on SOLR-13529:
-------------------------------------

 

Adding to the comment here: 
https://issues.apache.org/jira/browse/SOLR-13527?focusedCommentId=16859595&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16859595
{code:xml}
<processor class="FQN of class implementing this processor">
  <str name="numfieldschecker.enabled">true</str>
  <str name="numfieldschecker.dryRun">false</str>
  <str name="numfieldschecker.cutoff">512</str>
</processor>{code}
*cutoff* - defines the number of max fields in a core before which the update 
requests start getting rejected. This includes the explicitly defined fields, 
as well as dynamic fields that exist in the index.

Once the cutoff limit is set, there is no automatic way at present to fix the 
situation. If shard splitting is an option, it will mitigate the problem, but 
there is no guarantee around this being a solution.

Another option is to delete documents or migrate them.


Deletion of fields should ALWAYS be disabled as once a document with field 'x' 
is in the index, merely deleting the field from the schema doesn't mean that 
the field is gone. Also, this field could then be re-added with e different and 
conflicting definition causing more issues. 

 

> Control requests to Solr based on number of fields in a core
> ------------------------------------------------------------
>
>                 Key: SOLR-13529
>                 URL: https://issues.apache.org/jira/browse/SOLR-13529
>             Project: Solr
>          Issue Type: Sub-task
>            Reporter: Anshum Gupta
>            Priority: Major
>
> When the number of fields defined in a specific core grows to a very high 
> value, it is generally a better idea to reject or at least notify about the 
> situation so the user as well as the owner can address the problem.
> P.S: Yes, this should be addressed at a much earlier stage, but generally 
> isn't the case.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to