[
https://issues.apache.org/jira/browse/SOLR-13527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859595#comment-16859595
]
Anshum Gupta commented on SOLR-13527:
-------------------------------------
As I plan to use this Jira to put up the patch for the framework for the
underlying implementations to control updates, here's whatI'm currently working
on:
This will be implemented as an UpdateRequestProcessor, but in a way that allows
for easily adding more similar request limiter implementations. All of these
processors will watch the appropriate znodes and share the information w.r.t.
blocking/unblocking via zk.
*Enabling the limiter:*
# solrconfig.xml
Define the update request processor to be a part of the update chain that is
used. Define the default config values to block and unblock here.
# Cluster property
In addition to adding the update request processor in solrconfig.xml, we can
specify the block/unblock thresholds using values as a cluster property. This
will allow for setting a common value that applies to the entire cluster.
# Collection property
The properties that are defined above, can also be defined at a finer level
i.e. collection level.
*Order of preference:*
(least order of preference) solrconfig.xml < cluster property < collection
property (highest order of preference)
*Setting property values:*
The way that it is handled in the current implementation I'm working with is
that each processor/blocker defines properties that generally look like:
{{<implementation_name>.dryRun}}
{{<implementation_name>.blockLevel}}
{{<implementation_name>.param_name}}
Please look at the sub-tasks for this Jira that contain specific implementation
for getting an idea on what these params might look like.
P.S: We have been using this at work for a while now, and I'm in the process of
forward porting this and cleaning it up.
> Control update requests based on usage
> --------------------------------------
>
> Key: SOLR-13527
> URL: https://issues.apache.org/jira/browse/SOLR-13527
> Project: Solr
> Issue Type: New Feature
> Reporter: Anshum Gupta
> Assignee: Anshum Gupta
> Priority: Major
>
> Solr is open ended by design, and while that works for use cases where the
> owner and user of the Solr cluster are the same set of people, it quickly
> gets unmanageable when that’s not the case. As an example, there is no
> restriction on the core size or the number of fields that can be defined.
> It would be very useful to have an extendible way to be able to control and
> limit the way Solr is used from a platform perspective. Not only would the
> owner of Solr cluster/service be happy this way, the users would also get a
> much better uptime.
> This is an umbrella JIRA for a framework that allows for controlling access
> to Solr based on usage e.g.: core size, number of fields
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
