Description
The intent of this ticket is to have all distributed search requests stop wasting CPU cycles on requests that have already timed out or are so complicated that they won't be able to execute. We have come across a case where a nasty wildcard query within a proximity clause was causing the cluster to enumerate terms for hours even though the query timeout was set to minutes. This caused a noticeable slowdown within the system which made us restart the replicas that happened to service that one request, the worst case scenario are users with a relatively low zk timeout value will have nodes start dropping from the cluster due to long GC pauses.
amccurry Built a mechanism into Apache Blur to help with the issue in BLUR-142 (see commit comment for code, though look at the latest code on the trunk for newer bug fixes).
Solr should be able to either prevent these problematic queries from running by some heuristic (possibly estimated size of heap usage) or be able to execute a thread interrupt on all query threads once the time threshold is met. This issue mirrors what others have discussed on the mailing list: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3C856ac15f0903272054q2dbdbd19kea3c5ba9e105b9d8@mail.gmail.com%3E
Attachments
Attachments
Issue Links
- is related to
-
SOLR-6831 Make facet pivots respect timeout from SolrQueryTimeoutImpl
- Open
-
SOLR-6623 NPE in StoredFieldsShardResponseProcessor possible when using TIME_ALLOWED param
- Resolved
-
SOLR-6930 Provide "Circuit Breakers" For Expensive Solr Queries
- Resolved
- relates to
-
LUCENE-9036 ExitableDirectoryReader to interrupt DocValues as well
- Closed
-
SOLR-6564 Fix failing ExitableDirectoryReader tests for Solr
- Closed