[
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: [email protected]
For additional commands, e-mail: [email protected]