[ 
https://issues.apache.org/jira/browse/SOLR-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Potter updated SOLR-6761:
---------------------------------
    Attachment: SOLR-6761.patch

Moving forward with the updateRequestProcessor approach. Latest patch includes 
a unit test. To activate this request processor you'll need to add something 
like the following to your solrconfig.xml:

{code}
  <updateRequestProcessorChain name="ignore-commit-from-client" default="true">
    <processor class="solr.IgnoreCommitOptimizeUpdateProcessorFactory">
      <int name="statusCode">200</int>
    </processor>
    <processor class="solr.LogUpdateProcessorFactory" />
    <processor class="solr.DistributedUpdateProcessorFactory" />
    <processor class="solr.RunUpdateProcessorFactory" />
  </updateRequestProcessorChain>
{code}

As shown in the example above, the processor will return 200 to the client but 
will ignore the commit / optimize request. Notice that you need to wire-in the 
implicit processors needed by SolrCloud as well since this custom chain is 
taking the place of the default chain.

In the following example, the processor will raise an exception with a 403 code 
with a customized error message:

{code}
  <updateRequestProcessorChain name="ignore-commit-from-client" default="true">
    <processor class="solr.IgnoreCommitOptimizeUpdateProcessorFactory">
      <int name="statusCode">403</int>
      <str name="responseMessage">Thou shall not issue a commit!</str>
    </processor>
    <processor class="solr.LogUpdateProcessorFactory" />
    <processor class="solr.DistributedUpdateProcessorFactory" />
    <processor class="solr.RunUpdateProcessorFactory" />
  </updateRequestProcessorChain>
{code}

Lastly, you can also configure it to just ignore optimize and let commits pass 
thru by doing:

{code}
  <updateRequestProcessorChain name="ignore-optimize-only-from-client-403">
    <processor class="solr.IgnoreCommitOptimizeUpdateProcessorFactory">
      <str name="responseMessage">Thou shall not issue an optimize, but commits 
are OK!</str>
      <bool name="ignoreOptimizeOnly">true</bool>
    </processor>
    <processor class="solr.RunUpdateProcessorFactory" />
  </updateRequestProcessorChain>
{code}

One idea I had for making this easier to turn on globally would be to wire it 
into the implicit chain definition (in SolrCore). The patch doesn't do this 
yet, but in SolrCore, when the implicit chain is setup, we could enable this if 
the node is in SolrCloud mode and a system property 
(solr.ignoreCommitOptimizeFromClients=both|optimize) is set.

> 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
>            Assignee: Timothy Potter
>         Attachments: SOLR-6761.patch, SOLR-6761.patch
>
>
> 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