[
https://issues.apache.org/jira/browse/SOLR-6760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707457#comment-14707457
]
Gregory Chanan commented on SOLR-6760:
--------------------------------------
The naming here conflicts a bit with what I was trying to accomplish with
SOLR-7789, so I'm asking here for suggestions on how to resolve. In SOLR-7789
I am trying to accomplish the following:
#1 Add another OverseerMessageHandler (OverseerConfigSetMessageHandler) to
handle ConfigSet-related operations.
#2 From the perspective of the non-overseer (i.e. the ConfigSetsHandler), it
looks like the operations are written to a separate queue from the collection
queue, i.e. getOverseerConfigSetQueue()
#3 Since the ConfigSet operations are most likely rare and fast, it made sense
to just use the existing collections queue "under the covers" and handle the
dispatch separately. The naming here breaks the illusion of #2, i.e. if I
return an OverseerCollectionQueue it's pretty obvious to the non-overseer
what's going on.
So, here's my plan:
Short term: rename OverseerCollectionQueue to something more
generic...DistributedTaskQueue? DistributedAsyncAwareQueue? There's nothing
in there that is actually collection specific (which is why it works for the
ConfigSet operations)
Longer term: I have some more suggestions for the queue interface in
SOLR-7789. For example, on the insertion side the queue should be ZKNodeProps
based rather than byte [] based so we can return different queue types that
understand the semantics of the operations being inserted (hard to do that with
a byte []). In particular, I want to prefix all operation names to the
ConfigSetQueue with "configsets:" automatic to simplify the dispatching to the
correct OverseerMessageHandler. The ConfigSetsHandler needs to do this now (so
sort of breaks the illusion of #2) because of the interface. There's probably
a lot more room to break things up for client vs processing side as well --
i.e. why does the CollectionsHandler / ConfigSetsHandler get access to an
object that lets it remove something from the queue?
> New optimized DistributedQueue implementation for overseer
> ----------------------------------------------------------
>
> Key: SOLR-6760
> URL: https://issues.apache.org/jira/browse/SOLR-6760
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Noble Paul
> Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-6760-branch_5x.patch, SOLR-6760.patch,
> SOLR-6760.patch, 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
