[
https://issues.apache.org/jira/browse/SOLR-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860617#comment-17860617
]
Jason Gerlowski commented on SOLR-17351:
----------------------------------------
The main reason to defer updating Solr's internal usage in 9.x is that it risks
breaking users in the midst of a minor version upgrade. e.g. Imagine you're
doing a rolling-upgrade from 9.5 to 9.8, with nodes on a mixture of those two
versions. If a 9.8 node makes an internal filestore API call to another part
of the cluster, it can't use the "new" version of the API because the request
might be going to a node that's still on 9.5 (which won't have the "new" API
yet).
I'm tempted to say: "Why don't we just document that users should avoid
package-manager/file-store operations during an upgrade?" But even that
wouldn't necessarily solve the problem, because I imagine Solr does a bunch of
package-manager/file-store stuff internally on startup (e.g. so that it can
fetch any jars, etc. that it's supposed to have on the classpath). So even if
users don't make any explicit calls to the package-manager, upgrades will still
be broken and messy if our internal usage starts assuming an API that might not
be available on all nodes in the cluster.
If there's some way around that, I'd love to be more aggressive and change the
internal-usage for 9.x. But I can't see a way around it. Maybe someone with
more package-store knowledge could correct or confirm my suspicions here.
> Cosmetic changes to v2 filestore "get file" API
> -----------------------------------------------
>
> Key: SOLR-17351
> URL: https://issues.apache.org/jira/browse/SOLR-17351
> Project: Solr
> Issue Type: Sub-task
> Components: Package Manager, v2 API
> Affects Versions: 9.6.1
> Reporter: Jason Gerlowski
> Priority: Minor
>
> Solr's filestore APIs fit well with the REST-ful design we're targeting with
> our v2 APIs, with one large exception: the "get file" API current available
> at {{GET /api/node/files/somePath.txt}}. This API stands out for a few
> reasons:
> 1. It uses a different path-prefix than all other filestore APIs. (i.e.
> {{/api/node/files}} instead of {{/api/cluster/files}})
> 2. It exposes 4 or 5 conceptually distinct operations. Obviously in the
> "default" case it allows callers to retrieve filestore contents, but based on
> query params it can instead:
> - return filestore entry metadata (when {{meta=true}} is specified)
> - instruct the receiving Solr node to pull a file from another node's
> filestore and cache it locally (when {{getFrom=someOtherNode}} is specified)
> - instruct the receiving Solr node to push its cached copy of a file out to
> all other Solr nodes (when {{sync=true}} is specified)
> 3. Even in the default case of returning "raw" filestore contents, the API
> can provide two different styles of response:
> - if {{wt=json}} is specified Solr will take the filestore entry bytes,
> attempt to stringify them, and then return a JSON object that uses this
> string as the value for a "response" key. It's unclear how this would work
> for binary content
> - for all other values of "wt", the API will return the raw file content.
> We should reconsider this endpoint and see if it can't be massaged into being
> more in line with our other v2 APIs. Some cosmetic tweaks will go a long
> way, but the biggest benefit is likely to come from breaking the endpoint up
> into multiple distinct APIs. In its current form, the API returns such a
> variety of responses that it's hard to write client code for. (I suspect
> this is the main reason these "filestore" APIs were never made available in
> SolrJ.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
