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

Gus Heck commented on SOLR-15892:
---------------------------------

Your title and description are at odds with the change you are suggesting. (the 
current code IS selecting a "fixed" shard (the first in the list) and then 
finding it's leader, and your new code randomizes the selection). 

The following is based on memory several years old, not able to directly 
investigate now so forgive me if I forgot something here, but can you explain 
what issue you observed that motivates the change? It looks like the current 
code could theoretically lead to an over burdened node, but only if deletes and 
commits are very frequent (not having checked the assumption in your 
description that this only applies to commits and deletes yet). Such a design 
is possibly questionable to begin with. Sounds like situations with commit 
being sent with every update? Or maybe massive iterative deletions by id rather 
than using delete by query? Seems like there is potential for an X Y issue 
here. 

> RoutedAliasUpdateProcessor not distributing delete and commit requests.
> -----------------------------------------------------------------------
>
>                 Key: SOLR-15892
>                 URL: https://issues.apache.org/jira/browse/SOLR-15892
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>    Affects Versions: 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8, main (9.0), 8.9, 
> 8.10, 8.11
>            Reporter: Ankur Gupta
>            Priority: Minor
>             Fix For: main (9.0), 8.11
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, the RoutedAliasUpdateProcessor is not distributing and forwarding 
> all delete and commit requests for a RoutedAlias to a fixed shard leader.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

Reply via email to