[ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org