[ 
https://issues.apache.org/jira/browse/SOLR-11423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188866#comment-16188866
 ] 

ASF GitHub Bot commented on SOLR-11423:
---------------------------------------

GitHub user dragonsinth opened a pull request:

    https://github.com/apache/lucene-solr/pull/256

    SOLR-11423: Overseer queue needs a hard cap (maximum size) that clients 
respect

    

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/apache/lucene-solr SOLR-11423

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/lucene-solr/pull/256.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #256
    
----
commit ef8e0934fb27530f0c9450b58872b2b11028f50a
Author: Scott Blum <dragonsi...@apache.org>
Date:   2017-10-02T20:50:57Z

    SOLR-11423: Overseer queue needs a hard cap (maximum size) that clients 
respect

----


> Overseer queue needs a hard cap (maximum size) that clients respect
> -------------------------------------------------------------------
>
>                 Key: SOLR-11423
>                 URL: https://issues.apache.org/jira/browse/SOLR-11423
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: SolrCloud
>            Reporter: Scott Blum
>            Assignee: Scott Blum
>
> When Solr gets into pathological GC thrashing states, it can fill the 
> overseer queue with literally thousands and thousands of queued state 
> changes.  Many of these end up being duplicated up/down state updates.  Our 
> production cluster has gotten to the 100k queued items level many times, and 
> there's nothing useful you can do at this point except manually purge the 
> queue in ZK.  Recently, it hit 3 million queued items, at which point our 
> entire ZK cluster exploded.
> I propose a hard cap.  Any client trying to enqueue a item when a queue is 
> full would throw an exception.  I was thinking maybe 10,000 items would be a 
> reasonable limit.  Thoughts?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to