[jira] [Updated] (SOLR-9378) Avoid sending the shard.url parameter in shard requests

["Chris M. Hostetter (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-9378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris M. Hostetter updated SOLR-9378:
-------------------------------------
       Attachment: SOLR-9378.patch
    Fix Version/s:     (was: 7.0)
                       (was: 6.2)
         Assignee: Chris M. Hostetter
           Status: Open  (was: Open)

Attaching a patch suitable for main & backport to 9x.

This goes a little beyond what I originally advocated – the backcompat support is still there, but it's via a {{style}} localparam, which can have a default specified in an (explicit) augmenter registration in {{solrconfig.xml}} ... this is inspired by how the {{explain}} augmenter works.

If neither are specified, then the implicit default behavior is driven by the luceneMatchVersion.

The patch also includes a test for the situation described in SOLR-13595 with a test proving that te {{shards}} augmenter now works in this situation.

After backporting to 9x, the deprecated {{SHARD_URL}} param can be deleted from main.

 

> Avoid sending the shard.url parameter in shard requests
> -------------------------------------------------------
>
>                 Key: SOLR-9378
>                 URL: https://issues.apache.org/jira/browse/SOLR-9378
>             Project: Solr
>          Issue Type: Improvement
>          Components: search, SolrCloud
>            Reporter: Shalin Shekhar Mangar
>            Assignee: Chris M. Hostetter
>            Priority: Minor
>         Attachments: SOLR-9378.patch
>
>
> The shard.url parameter contains a list of all replicas for a shard. One of those is chosen by the HttpShardHandler to execute the request. So, it is used only within the context of processing request on a distributor node as a special storage for a list of replicas urls between the prep and execution phase of HttpShardHandler. There is no real need to send this parameter down to the chosen shard.
> However, Hoss pointed out to me that removing this would break ShardAugmenterFactory so we need to figure out if/how we can do this. Personally, I don't think it is at all useful to write down ​*all*​ replicas with the document without telling which replica really served the query.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org