[
https://issues.apache.org/jira/browse/SOLR-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-8677:
----------------------------------
Attachment: SOLR-8677.patch
Updated the patch with the changes to SolrJ that Shai suggested. A few notes:
- SolrJ now throws an "InvalidIdentifierException" (extends
IllegalArgumentException) when an invalid shard/core/collection/alias name is
provided. I wasn't sure whether it's acceptable to add a new thrown exception
type, or if SolrJ had conventions around this. Might be onerous to ask callers
to add an additional catch block into their code. But grepping through SolrJ's
code, I saw a variety of exceptions being thrown, so I took that as a sign that
I was "in the clear".
- The existing identifier-validation logic (on the server side) threw a
SolrException directly. This makes sense on the server side, but less so in
SolrJ. So I created a client-side validation class to throw a more appropriate
exception (InvalidIdentifierException, as mentioned above). This obviously
means some duplicated code, since the classes are largely the same other than
the exception being thrown. If anyone has suggestions on better ways to
structure this, I'd love to hear them.
- I added tests for the additional SolrJ checks. I had a hard time finding any
tests for the Collection-API related types in SolrJ (CollectionAdminRequest).
So I created a new file for these tests (TestCollectionAdminRequest). Wanted
to mention it, in case tests for those classes do already exist, and I just
missed them. Pretty sure the new file was warranted though.
Hope this covers what you were looking for Shai!
> SOLR allows creation of shards with invalid names.
> --------------------------------------------------
>
> Key: SOLR-8677
> URL: https://issues.apache.org/jira/browse/SOLR-8677
> Project: Solr
> Issue Type: Bug
> Affects Versions: master
> Reporter: Jason Gerlowski
> Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8677.patch, SOLR-8677.patch
>
>
> Solr currently has "recommendations" about what constitutes a valid
> identifier, but doesn't enforce these "recommendations" uniformly. Core
> (SOLR-8308) and collection (SOLR-8642) names are currently checked, but
> shards aren't.
> {code}
> $ bin/solr -e cloud -noprompt
> ....
> $ curl -i -l -k -X GET
> "http://localhost:8983/solr/admin/collections?action=CREATE&name=coll1&router.name=implicit&numShards=1&shards=bad+shard+name";
> HTTP/1.1 200 OK
> Content-Type: application/xml; charset=UTF-8
> Transfer-Encoding: chunked
> <?xml version="1.0" encoding="UTF-8"?>
> <response>
> <lst name="responseHeader"><int name="status">0</int><int
> name="QTime">204</int></lst><lst
> name="failure"><str>org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
> from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore
> 'coll1_bad shard name_replica1': Unable to create core [coll1_bad shard
> name_replica1] Caused by: Invalid name: 'coll1_bad shard name_replica1'
> Identifiers must consist entirely of periods, underscores and
> alphanumerics</str></lst>
> </response>
> {code}
> (Note that the CREATE command above returned 200-OK, and the failure was only
> apparent when viewing the message.)
> A CLUSTERSTATUS shows that the shard was actually created, but has no
> underlying cores.
> {code}
> $ curl -i -l -k -X GET
> "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS&wt=json&indent=true";
> ...
> "collections":{
> "coll1":{
> "replicationFactor":"1",
> "shards":{"bad shard name":{
> "range":null,
> "state":"active",
> "replicas":{}}},
> "router":{"name":"implicit"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "znodeVersion":1,
> "configName":"gettingstarted"},
> ...
> {code}
> This JIRA proposes adding a check to ensure that shard names meet SOLR's
> identifier "recommendations". This should prevent users from accidentally
> putting themselves in a bad state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
