You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Scott Blum (JIRA)" <ji...@apache.org> on 2016/06/08 18:20:21 UTC

[jira] [Comment Edited] (SOLR-9191) OverseerTaskQueue.peekTopN() fatally flawed

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

Scott Blum edited comment on SOLR-9191 at 6/8/16 6:19 PM:
----------------------------------------------------------

Cool.  Any other feedback beyond the Predicate change?  [~shalinmangar] or [~markrmiller@gmail.com]?  Otherwise going to commit to master today and start backporting.

I want to backport this to any branches we might make a release on... 5.5.2, 5.6, 6.0.2, 6.1.1, 6.2


was (Author: dragonsinth):
Cool.  Any other feedback beyond the Predicate change?  [~shalinmangar] or [~markrmiller@gmail.com]?  Otherwise going to commit to master today and start backporting.

I want to backport this to any branches we might make a release on... 5.5.2, 5.6, 6.0.2, 6.1

> OverseerTaskQueue.peekTopN() fatally flawed
> -------------------------------------------
>
>                 Key: SOLR-9191
>                 URL: https://issues.apache.org/jira/browse/SOLR-9191
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 5.4, 5.4.1, 5.5, 5.5.1, 6.0, 6.0.1
>            Reporter: Scott Blum
>            Assignee: Scott Blum
>            Priority: Blocker
>             Fix For: 5.6, 6.1, 5.5.2, 6.0.2, 6.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> We rewrote DistributedQueue in SOLR-6760, to optimize its obvious use case as a FIFO.  But in doing so, we broke the assumptions in OverseerTaskQueue.peekTopN()..
> OverseerTaskQueue.peekTopN() involves filtering out items you're already working on, it's trying to peek for new items in the queue beyond what you already know about.  But DistributedQueue (being designed as a FIFO) doesn't know about the filtering; as long as it has any items in-memory it just keeps returning those over and over without ever pulling new data from ZK.  This is true even if the watcher has fired and marked the state as dirty.  So OverseerTaskQueue gets into a state where it can never read new items in ZK because DQ keeps returning the same items that it has marked as in-progress.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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