[ https://issues.apache.org/jira/browse/SOLR-6760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14703053#comment-14703053 ]
Shalin Shekhar Mangar commented on SOLR-6760: --------------------------------------------- I saw test failures twice in a row but I can't reproduce them on beasting. Looking at the test itself I can't figure out why it would fail like this: {code} java.util.NoSuchElementException at __randomizedtesting.SeedInfo.seed([FD3C9C458FB6F5FD:9E2CC8B3009169AB]:0) at org.apache.solr.cloud.DistributedQueue.remove(DistributedQueue.java:203) at org.apache.solr.cloud.DistributedQueueTest.testDistributedQueue(DistributedQueueTest.java:62) {code} Perhaps related to the tests being executed in a wrong order? Maybe each test method should get its own ZK server or at least a different znode path for the queue? In case it helps, the seeds were: {code} ant test -Dtestcase=DistributedQueueExtTest -Dtests.method=testDistributedQueue -Dtests.seed=F156B17A5CB6EA4 -Dtests.slow=true -Dtests.locale=ca -Dtests.timezone=Europe/Vilnius -Dtests.asserts=true -Dtests.file.encoding=UTF-8 ant test -Dtestcase=DistributedQueueTest -Dtests.method=testDistributedQueue -Dtests.seed=FD3C9C458FB6F5FD -Dtests.slow=true -Dtests.locale=en_AU -Dtests.timezone=Australia/Lindeman -Dtests.asserts=true -Dtests.file.encoding=UTF-8 {code} > New optimized DistributedQueue implementation for overseer > ---------------------------------------------------------- > > Key: SOLR-6760 > URL: https://issues.apache.org/jira/browse/SOLR-6760 > Project: Solr > Issue Type: Bug > Reporter: Noble Paul > Assignee: Shalin Shekhar Mangar > Attachments: SOLR-6760.patch, SOLR-6760.patch, deadlock.patch > > > Currently the DQ works as follows > * read all items in the directory > * sort them all > * take the head and return it and discard everything else > * rinse and repeat > This works well when we have only a handful of items in the Queue. If the > items in the queue is much larger (in tens of thousands) , this is > counterproductive > As the overseer queue is a multiple producers + single consumer queue, We can > read them all in bulk and before processing each item , just do a > zk.exists(itemname) and if all is well we don't need to do the fetch all + > sort thing again -- 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