[
https://issues.apache.org/jira/browse/SOLR-12465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16505167#comment-16505167
]
Andrzej Bialecki commented on SOLR-12465:
------------------------------------------
It makes sense to me what you mentioned in the other issue - that triggers may
consider a fraction of {{waitFor}} as the basis for how often they check
cluster state. However, this depends on trigger implementation and how likely
it is to miss important state change between samples.
In case of nodeLost / nodeAdded the condition will persist for a relatively
long time, so it makes sense to track it less closely (although we need to
consider the "flaky node" scenario too, see SOLR-11730). Search rate trigger
samples a 1-min average metric, so it's probably also ok if it checks less
frequently.
Triggers should also check that their {{waitFor}} is at least twice as long as
the `triggerScheduleDelaySeconds`.
> Triggers should look at metrics less often
> ------------------------------------------
>
> Key: SOLR-12465
> URL: https://issues.apache.org/jira/browse/SOLR-12465
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
> Reporter: Varun Thacker
> Priority: Major
>
> As soon as I create a search rate trigger I see that the metrics endpoint is
> being queried every 1 second . As discussed on SOLR-12463 we should change
> the default to be 10 seconds
> Example trigger
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-trigger": {
> "name" : "search_rate_trigger",
> "event" : "searchRate",
> "collection" : "test_rate_trigger",
> "rate" : 1.0,
> "waitFor" : "1m",
> "enabled" : true,
> "actions" : [
> {
> "name" : "compute_plan",
> "class": "solr.ComputePlanAction"
> },
> {
> "name" : "execute_plan",
> "class": "solr.ExecutePlanAction"
> }
> ]
> }
> }' http://localhost:8983/solr/admin/autoscaling
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
