[
https://issues.apache.org/jira/browse/SOLR-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134487#comment-14134487
]
Anshum Gupta edited comment on SOLR-5986 at 9/16/14 2:34 AM:
-------------------------------------------------------------
Thanks Robert for the review. Updated the patch with most of your feedback +
recommendations.
I didn't change the design from using a ThreadLocal to passing the timeout in
the constructor as the user might pre-construct and reuse the reader/searcher.
(Solr specifically wouldn't play well with such a change).
I did consider doing it that way but wasn't able figure out a way to do that.
I'll just spend some more time to see if there's a clean way to do it (have the
timeout be a passed parameter to the constructor instead of being ThreadLocal).
About the test relying on system clock, not really that much as the sleep in
wrapped up .next() and the timeout values are not even close.
Also, I can't figure out how to view the review on the review board (doesn't
show up for me and the mail went to spam until Steve mentioned about the
email). I've posted the updated patch there to make it easier for everyone to
look at it.
was (Author: anshumg):
Thanks Robert for the review. Updated the patch with most of your feedback +
recommendations.
I didn't change the design from using a ThreadLocal to passing the timeout in
the constructor as the user might pre-construct and reuse the reader/searcher.
(Solr specifically wouldn't play well with such a change).
I did consider doing it that way but wasn't able figure out a way to do that.
I'll just spend some more time to see if there's a clean way to do it.
About the test relying on system clock, not really that much as the sleep in
wrapped up .next() and the timeout values are not even close.
Also, I can't figure out how to view the review on the review board (doesn't
show up for me and the mail went to spam until Steve mentioned about the
email). I've posted the updated patch there to make it easier for everyone to
look at it.
> Don't allow runaway queries from harming Solr cluster health or search
> performance
> ----------------------------------------------------------------------------------
>
> Key: SOLR-5986
> URL: https://issues.apache.org/jira/browse/SOLR-5986
> Project: Solr
> Issue Type: Improvement
> Components: search
> Reporter: Steve Davids
> Assignee: Anshum Gupta
> Priority: Critical
> Fix For: 4.10
>
> Attachments: SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch,
> SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch,
> SOLR-5986.patch
>
>
> 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/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
