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

David Smiley commented on SOLR-17293:
-------------------------------------

Thanks for telling me about QUIT.  I see it's used for the workings of the 
overseer role (in OverseerNodePrioritizer).  I guess the "/overseer/queue" will 
at least have to stay for now.

No, the motivation doesn't have to do with SolrJ.  SolrJ doesn't talk to the 
Overseer or otherwise care about it in any way I can think of.  The linked PR 
here, #3643 explicitly set the overseerEnabled=false if it's not set but it 
occurred to me that the presence of /overseer should mean not to default to 
overseerEnabled=false, and even if it's not set, then it need not set the 
cluster property either.  It's kind of confusing but the goal is to play it 
safe if a cluster was created with the Overseer (say Solr 9) then it stays that 
way unless an operator makes an explicit decision.

> Umbrella: Decentralized Cluster Processing as default
> -----------------------------------------------------
>
>                 Key: SOLR-17293
>                 URL: https://issues.apache.org/jira/browse/SOLR-17293
>             Project: Solr
>          Issue Type: Improvement
>          Components: SolrCloud
>            Reporter: David Smiley
>            Priority: Blocker
>              Labels: pull-request-available
>             Fix For: main (10.0)
>
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> This is an umbrella issue for tracking work required for running SolrCloud 
> with two booleans as default: {{distributedClusterStateUpdates}} and 
> {{distributedCollectionConfigSetExecution}}, which we may rename/refactor 
> (TBD).  When they are set, the Overseer has nothing to do except run "Cluster 
> Singleton Plugins" (if you configure any).
> These have been in Solr for years since well before 9.0 and are tested in a 
> randomized fashion.  But they have not experienced real-world usage to our 
> knowledge.  There are some scalability concerns, and unclear compatibility 
> with PRS.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to