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

Ramkumar Aiyengar commented on SOLR-6761:
-----------------------------------------

I like the idea, with the minor exception that it sounds wrong to return 200 
instead of a 4xx. The client is doing some effort to add the commit request and 
should know that it's not been respected. If it breaks them, so be it, they are 
doing something the system is not configured to do. They might actually even 
rely on the assumption that once the commit is done it's immediately available 
for search..

> Ability to ignore commit and optimize requests from clients when running in 
> SolrCloud mode.
> -------------------------------------------------------------------------------------------
>
>                 Key: SOLR-6761
>                 URL: https://issues.apache.org/jira/browse/SOLR-6761
>             Project: Solr
>          Issue Type: New Feature
>          Components: SolrCloud, SolrJ
>            Reporter: Timothy Potter
>
> In most SolrCloud environments, it's advisable to only rely on auto-commits 
> (soft and hard) configured in solrconfig.xml and not send explicit commit 
> requests from client applications. In fact, I've seen cases where improperly 
> coded client applications can send commit requests too frequently, which can 
> lead to harming the cluster's health. 
> As a system administrator, I'd like the ability to disallow commit requests 
> from client applications. Ideally, I could configure the updateHandler to 
> ignore the requests and return an HTTP response code of my choosing as I may 
> not want to break existing client applications by returning an error. In 
> other words, I may want to just return 200 vs. 405. The same goes for 
> optimize requests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Reply via email to