solr servers to load balance, those are regularly tested.
a function that returns the collection name and a testQuery for the given server. The collection is used to partition server when classifying "fast"/"slow" servers, because for different collections response times will be different. It's somehow similar with the testQuery: it might be different per server, e.g. some server might only provide a /suggest handler while others provide /select (which can be specified via the "qt" query param in the test query).
the minimum delay between the response of a test and the start of the next test (to limit test frequency)
the delay between tests for slow servers (or all servers if there are no real requests)
on start each active server is tested the given number of times to gather initial stats and determine fast/slow servers.
a function to filter fast / preferred servers. The function takes the calculated average duration
of all servers of a collection, and returns a function for a SolrServer->Duration tuple
that returns true/false to indicate if a server should be considered "fast".
The default value for filterFastServers uses duration <= average * 1.1 + 5 (use
1.1 as multiplier to accepted some deviation, for smaller values like 1 or 2 millis
also add some fix value to allow normal deviation).
a function that's applied to the predicted response time. This can e.g. be used to quantize the time so that minor differences are ignored.
the clock to get the current time from. The tests using the maxDelay are run using a scheduled executor, therefore this interval uses the system clock
a function that returns the collection name and a testQuery for the given server.
a function that returns the collection name and a testQuery for the given server. The collection is used to partition server when classifying "fast"/"slow" servers, because for different collections response times will be different. It's somehow similar with the testQuery: it might be different per server, e.g. some server might only provide a /suggest handler while others provide /select (which can be specified via the "qt" query param in the test query).
Intercept user queries to trigger test queries based on the current request rate.
Intercept user queries to trigger test queries based on the current request rate.
the function to intercept
the SolrServer that's used to run the query
the query to send to solr.
the query response.
a function that's applied to the predicted response time.
a function that's applied to the predicted response time. This can e.g. be used to quantize the time so that minor differences are ignored.
On creation of AsyncSolrClient this method is invoked with the created instance if the concrete component is "supported", right now this are SolrServers and LoadBalancer.
On creation of AsyncSolrClient this method is invoked with the created instance if the concrete component is "supported", right now this are SolrServers and LoadBalancer. Subclasses can override this method to get access to the solr client.
Determines the solr server to use for a new request.
Determines the solr server to use for a new request.
solr servers to load balance, those are regularly tested.
solr servers to load balance, those are regularly tested.
Determines the servers that are tested more frequently.
Determines the servers that are tested more frequently.
LB strategy that selects the fastest server based on the latest average response time. It's aimed to handle a multi datacenter setup where some server regularly need longer to response. It shall also detect short (subsecond) pauses of a server e.g. due to garbage collection or s.th. else.
The latest average response time is determined in the following order (the first found measure is used): - currently still running requests (if they're lasting longer than previous, already completed requests) - average response time of the current or the last second - average response time of the last ten seconds - total average resonse time
The response time is measured using the given testQuery. A dedicated test query is used, because queries can have very different performance characteristics, so that it might even be hard for an application to classify this. With the testQuery you have control what is used to measure response time.
For "normal" / "fast" servers (default: with a resonse time <= the average of all servers, you can override
determineFastServers) test queries are run whenever a request comes in, but between test queries at least the minDelay has to be passed. This way servers are not hammered with requests when nobody else is using your search, but if there's high traffic this load balancer get high resolution of monitoring data to detect short pauses as well.For "slow" servers (default: response time > average) tests are run using the specified maxDelay.
Directly after creation of this LoadBalancer / AsnycSolrClient multiple test queries are run (according to the specified
initialTestRuns, by default 10) to have initial stats.