Re: Solr 8.0 query length limit
You can send big queries as a POST request instead of a GET request. Op do 18 feb. 2021 om 11:38 schreef Anuj Bhargava : > Solr 8.0 query length limit > > We are having an issue where queries are too big, we get no result. And if > we remove a few keywords we get the result. > > Error we get - error 414 (Request-URI Too Long) > > > Have made the following changes in jetty.xml, still the same error > > * name="solr.jetty.output.buffer.size" default="32768" />* > * name="solr.jetty.output.aggregation.size" default="32768" />* > * name="solr.jetty.request.header.size" default="65536" />* > * name="solr.jetty.response.header.size" default="32768" />* > * name="solr.jetty.send.server.version" default="false" />* > * name="solr.jetty.send.date.header" default="false" />* > * name="solr.jetty.header.cache.size" default="1024" />* > * name="solr.jetty.delayDispatchUntilContent" default="false"/>* >
Wrong HTTP status for HEAD request
Hi, In Solr 8.6.1, a GET request or a HEAD request for a non-existing term in a managed resource (stopword or synonym) returns a HTTP status "404 Not Found". $ curl -i " http://localhost:8983/solr/techproducts/schema/analysis/synonyms/english/foobar; | head -n 1 HTTP/1.1 404 Not Found $ curl -I " http://localhost:8983/solr/techproducts/schema/analysis/synonyms/english/foobar; | head -n 1 HTTP/1.1 404 Not Found In Solr 8.7.0, the same GET request still returns "404 Not Found", but the HEAD request now returns "200 OK" as if the term actually exists. $ curl -i " http://localhost:8983/solr/techproducts/schema/analysis/synonyms/english/foobar; | head -n 1 HTTP/1.1 404 Not Found $ curl -I " http://localhost:8983/solr/techproducts/schema/analysis/synonyms/english/foobar; | head -n 1 HTTP/1.1 200 OK I presume that's a bug? Thomas
Re: Why use a different analyzer for "index" and "query"?
Hi Steve I have a real-world use case. We don't apply a synonym filter at index time, but we do apply a managed synonym filter at query time. This allows content managers to add new synonyms (or remove existing ones) "on the fly" without having to reindex any documents. Thomas Op do 10 sep. 2020 om 17:29 schreef Dunham-Wilkie, Mike CITZ:EX < mike.dunham-wil...@gov.bc.ca>: > Hi Steven, > > I can think of one case. If we have an index of database table or column > names, e.g., words like 'THIS_IS_A_TABLE_NAME', we may want to split the > name at the underscores when indexing (as well as keep the original), since > the individual parts might be significant and meaningful. When querying, > though, if the searcher types in THIS_IS_A_TABLE_NAME then they are likely > looking for the whole string, so we wouldn't want to split it apart. > > There also seems to be a debate on whether the SYNONYM filter should be > included on indexing, on querying, or on both. Google "solr synonyms index > vs query" > > Mike > > -Original Message- > From: Steven White > Sent: September 10, 2020 8:19 AM > To: solr-user@lucene.apache.org > Subject: Why use a different analyzer for "index" and "query"? > > [EXTERNAL] This email came from an external source. Only open attachments > or links that you are expecting from a known sender. > > > Hi everyone, > > In Solr's schema, I have come across field types that use a different > logic for "index" than for "query". To be clear, I"m talking about this > block: > > positionIncrementGap="100"> > > > > > > > > > Why would one want to not use the same logic for both and simply use: > > positionIncrementGap="100"> > > > > > > What are real word use cases to use a different analyzer for index and > query? > > Thanks, > > Steve >
Rule-Based permissions for cores
Hi,
I'm trying to configure the Rule-Based Authorization Plugin in Solr 8.4.0
in standalone mode. My goal is to limit a user's access to one or more
designated cores. My security.json looks like this:
{
"authentication":{
"blockUnknown":true,
"class":"solr.BasicAuthPlugin",
"credentials":{
"solr":"...",
"user1":"...",
"user2":"..."},
"realm":"Solr",
"forwardCredentials":false,
"":{"v":0}},
"authorization":{
"class":"solr.RuleBasedAuthorizationPlugin",
"permissions":[
{
"name":"security-edit",
"role":"admin",
"index":1},
{
"name":"read",
"collection":"core1",
"role":"role1",
"index":2},
{
"name":"read",
"collection":"core2",
"role":"role2",
"index":3},
{
"name":"all",
"role":"admin",
"index":4}],
"user-role":{
"solr":"admin",
"user1":"role1",
"user2":"role2"},
"":{"v":0}}}
With this setup, I'm unable to read from any of the cores with either user.
If I "delete-permission":4 both users can read from either core, not just
"their" core.
I have tried custom permissions like this to no avail:
{"name": "access-core1", "collection": "core1", "role": "role1"},
{"name": "access-core2", "collection": "core2", "role": "role2"},
{"name": "all", "role": "admin"}
Is it possible to do this for cores? Or am I out of luck because I'm not
using collections?
Regards
Thomas
Re: SynonymFilterFactory deprecated, documentation and search
Do keep this paragraph from the docs in mind when switching from a non-graph to a graph filter: If you use this filter during indexing, you must follow it with a Flatten Graph Filter to squash tokens on top of one another like the Synonym Filter, because the indexer can’t directly consume a graph. To get fully correct positional queries when your synonym replacements are multiple tokens, you should instead apply synonyms using this filter at query time. Regards, Thomas Op do 30 jul. 2020 10:17 schreef Colvin Cowie : > That does some like an unhelpful example to have, though > > https://lucene.apache.org/solr/guide/8_6/filter-descriptions.html#synonym-filter > does clearly state that it is deprecated in favour of > SynonymGraphFilterFactory . > Deprecated classes will (should) continue to work, but are likely to be > removed at some point, e.g. the next major release. IIRC (might be wrong > though) you can simply replace with SynonymFilterFactory with > SynonymGraphFilterFactory > and it should just work in most cases, but do test it. > > On Thu, 30 Jul 2020 at 07:52, Jayadevan Maymala > wrote: > > > Hi all, > > > > We have been using SynonymFilterFactory with Solr 7.3. It seems to be > > working, > > Going through the documentation for 8.6, I noticed that it was > deprecated a > > long time ago, probably before 7.3 > > The documentation at this url, for version 8.6 - > > > > > https://lucene.apache.org/solr/guide/8_6/field-type-definitions-and-properties.html > > does give > synonyms="index_synonyms.txt" ignoreCase="true" expand="false"/> as an > > example. > > Two doubts - > > Does a deprecated class continue working? > > Shouldn't the documentation be updated to modify the example? > > > > A request - if the documentation at the url mentioned above has a search, > > that will really help. I could find only a Page Title lookup. > > > > Regards, > > Jayadevan > > >
Tokenizing managed synonyms
Hi, Is it possible to specify a Tokenizer Factory on a Managed Synonym Graph Filter? I would like to use a Standard Tokenizer or Keyword Tokenizer on some fields. Best, Thomas
Re: Solr Float/Double multivalues fields
Op vr 3 jul. 2020 om 14:11 schreef Bram Van Dam : > On 03/07/2020 09:50, Thomas Corthals wrote: > > I think this should go in the ref guide. If your product depends on this > > behaviour, you want reassurance that it isn't going to change in the next > > release. Not everyone will go looking through the javadoc to see if this > is > > implied. > > This is in the ref guide. Section DocValues. Here's the quote: > > DocValues are only available for specific field types. The types chosen > determine the underlying Lucene > docValue type that will be used. The available Solr field types are: > • StrField, and UUIDField: > ◦ If the field is single-valued (i.e., multi-valued is false), Lucene > will use the SORTED type. > ◦ If the field is multi-valued, Lucene will use the SORTED_SET type. > Entries are kept in sorted order and > duplicates are removed. > • BoolField: > ◦ If the field is single-valued (i.e., multi-valued is false), Lucene > will use the SORTED type. > © 2019, Apache Software Foundation > Guide Version 7.7 - Published: 2019-03-04 > Page 212 of 1426 > Apache Solr Reference Guide 7.7 > ◦ If the field is multi-valued, Lucene will use the SORTED_SET type. > Entries are kept in sorted order and > duplicates are removed. > • Any *PointField Numeric or Date fields, EnumFieldType, and > CurrencyFieldType: > ◦ If the field is single-valued (i.e., multi-valued is false), Lucene > will use the NUMERIC type. > ◦ If the field is multi-valued, Lucene will use the SORTED_NUMERIC type. > Entries are kept in sorted order > and duplicates are kept. > • Any of the deprecated Trie* Numeric or Date fields, EnumField and > CurrencyField: > ◦ If the field is single-valued (i.e., multi-valued is false), Lucene > will use the NUMERIC type. > ◦ If the field is multi-valued, Lucene will use the SORTED_SET type. > Entries are kept in sorted order and > duplicates are removed. > These Lucene types are related to how the values are sorted and stored. > Great for docValues. But I couldn't find anything similar for multiValued in the field type pages of the ref guide (unless I totally missed it of course). It doesn't have to be as elaborate, as long as it's clear and doesn't leave users wondering or assuming.
Re: Solr Float/Double multivalues fields
I think this should go in the ref guide. If your product depends on this behaviour, you want reassurance that it isn't going to change in the next release. Not everyone will go looking through the javadoc to see if this is implied. Typically it'll either be something like "are always returned in insertion order" or "are currently returned in insertion order, but your code shouldn't rely on this behaviour because it can change in future releases". That's usually sufficient to make an informed decision on how to handle returned values. If it's different for docValues, that's even more reason to state it clearly in the ref guide to avoid confusion. Best, Thomas Op do 2 jul. 2020 om 20:37 schreef Erick Erickson : > This is true _unless_ you fetch from docValues. docValues are SORTED_SETs, > so the results will be both ordered and deduplicated if you return them > as part of the field list. > > Don’t really think it needs to go into the ref guide, it’s just inherent > in storing > any kind of value. You wouldn’t expect multiple text entries in a > multiValued > field to be rearranged when returning the stored values either. > > Best, > Erick > > > On Jul 2, 2020, at 2:21 PM, Vincenzo D'Amore wrote: > > > > Thanks, and genuinely asking: is there written somewhere in the > > documentation too? If no, could anyone suggest to me which doc page > should > > I try to update? > > > > On Thu, Jul 2, 2020 at 8:08 PM Colvin Cowie > > wrote: > > > >> The order of values within a multivalued field should match the > insertion > >> order. -- we certainly rely on that in our product. > >> > >> Order is guaranteed to be maintained for values in a multi-valued field. > >>> > >> > >> > https://lucene.472066.n3.nabble.com/order-question-on-solr-multi-value-field-tp4027695p4028057.html > >> > >> On Thu, 2 Jul 2020 at 18:52, Vincenzo D'Amore > wrote: > >> > >>> Hi all, > >>> > >>> simple question: Solr float/double multivalue fields preserve the order > >> of > >>> inserted values? > >>> > >>> Best regards, > >>> Vincenzo > >>> > >>> -- > >>> Vincenzo D'Amore > >>> > >> > > > > > > -- > > Vincenzo D'Amore > >
Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr
Since "overseer" is also problematic, I'd like to propose "orchestrator" as an alternative. Thomas Op vr 19 jun. 2020 04:34 schreef Walter Underwood : > We don’t get to decide whether “master” is a problem. The rest of the world > has already decided that it is a problem. > > Our task is to replace the terms “master” and “slave” in Solr. > > wunder > Walter Underwood > wun...@wunderwood.org > http://observer.wunderwood.org/ (my blog) > > > On Jun 18, 2020, at 6:50 PM, Rahul Goswami > wrote: > > > > I agree with Phill, Noble and Ilan above. The problematic term is "slave" > > (not master) which I am all for changing if it causes less regression > than > > removing BOTH master and slave. Since some people have pointed out Github > > changing the "master" terminology, in my personal opinion, it was not a > > measured response to addressing the bigger problem we are all trying to > > tackle. There is no concept of a "slave" branch, and "master" by itself > is > > a pretty generic term (Is someone having "mastery" over a skill a bad > > thing?). I fear all it would end up achieving in the end with Github is a > > mess of broken build scripts at best. > > So +1 on "slave" being the problematic term IMO, not "master". > > > > On Thu, Jun 18, 2020 at 8:19 PM Phill Campbell > > wrote: > > > >> Master - Worker > >> Master - Peon > >> Master - Helper > >> Master - Servant > >> > >> The term that is not wanted is “slave’. The term “master” is not a > problem > >> IMO. > >> > >>> On Jun 18, 2020, at 3:59 PM, Jan Høydahl > wrote: > >>> > >>> I support Mike Drob and Trey Grainger. We shuold re-use the > >> leader/replica > >>> terminology from Cloud. Even if you hand-configure a master/slave > cluster > >>> and orchestrate what doc goes to which node/shard, and hand-code your > >> shards > >>> parameter, you will still have a cluster where you’d send updates to > the > >> leader of > >>> each shard and the replicas would replicate the index from the leader. > >>> > >>> Let’s instead find a new good name for the cluster type. Standalone > kind > >> of works > >>> for me, but I see it can be confused with single-node. We have also > >> discussed > >>> replacing SolrCloud (which is a terrible name) with something more > >> descriptive. > >>> > >>> Today: SolrCloud vs Master/slave > >>> Alt A: SolrCloud vs Standalone > >>> Alt B: SolrCloud vs Legacy > >>> Alt C: Clustered vs Independent > >>> Alt D: Clustered vs Manual mode > >>> > >>> Jan > >>> > 18. jun. 2020 kl. 15:53 skrev Mike Drob : > > I personally think that using Solr cloud terminology for this would be > >> fine > with leader/follower. The leader is the one that accepts updates, > >> followers > cascade the updates somehow. The presence of ZK or election doesn’t > >> really > change this detail. > > However, if folks feel that it’s confusing, then I can’t tell them > that > they’re not confused. Especially when they’re working with others who > >> have > less Solr experience than we do and are less familiar with the > >> intricacies. > > Primary/Replica seems acceptable. Coordinator instead of Overseer > seems > acceptable. > > Would love to see this in 9.0! > > Mike > > On Thu, Jun 18, 2020 at 8:25 AM John Gallagher > wrote: > > > While on the topic of renaming roles, I'd like to propose finding a > >> better > > term than "overseer" which has historical slavery connotations as > well. > > Director, perhaps? > > > > > > John Gallagher > > > > On Thu, Jun 18, 2020 at 8:48 AM Jason Gerlowski < > gerlowsk...@gmail.com > >>> > > wrote: > > > >> +1 to rename master/slave, and +1 to choosing terminology distinct > >> from what's used for SolrCloud. I could be happy with several of > the > >> proposed options. Since a good few have been proposed though, maybe > >> an eventual vote thread is the most organized way to aggregate the > >> opinions here. > >> > >> I'm less positive about the prospect of changing the name of our > >> primary git branch. Most projects that contributors might come > from, > >> most tutorials out there to learn git, most tools built on top of > git > >> - the majority are going to assume "master" as the main branch. I > >> appreciate the change that Github is trying to effect in changing > the > >> default for new projects, but it'll be a long time before that > >> competes with the huge bulk of projects, documentation, etc. out > there > >> using "master". Our contributors are smart and I'm sure they'd > figure > >> it out if we used "main" or something else instead, but having a > >> non-standard git setup would be one more "papercut" in understanding > >> how to contribute to a project that already makes that harder than > it > >> should. > >> > >> Jason > >> > >> > >> On Thu, Jun 18, 2020 at 7:33
Re: Order of spellcheck suggestions
Can anybody shed some light on this? If not, I'm going to report it as a
bug in JIRA.
Thomas
Op za 13 jun. 2020 13:37 schreef Thomas Corthals :
> Hi
>
> I'm seeing different ordering on the spellcheck suggestions in cloud mode
> when using spellcheck.extendedResults=false vs.
> spellcheck.extendedResults=true.
>
> Solr 8.5.2 in cloud mode with 2 nodes, 1 collection with numShards = 2 &
> replicationFactor = 1, techproducts configset and example data:
>
> $ curl '
> http://localhost:8983/solr/techproducts/spell?q=power%20cort=false
> '
>
> "suggestion":["cord", "corp", "card"]}],
>
> $ curl '
> http://localhost:8983/solr/techproducts/spell?q=power%20cort=true
> '
>
> "suggestion":[{ "word":"corp", "freq":2}, { "word":"cord", "freq":1}, {
> "word":"card", "freq":4}]}],
>
> The correct order should be "corp" (LD: 1, freq: 2), "cord" (LD: 1, freq:
> 1) , "card" (LD: 2, freq: 4). In standalone mode, I get "corp", "cord",
> "card" with extendedResults true or false.
>
> The results are the same for the /spell and /browse request handlers in
> that configset. I've put all combinations side by side in this spreadsheet:
> https://docs.google.com/spreadsheets/d/1ym44TlbomXMCeoYpi_eOBmv6-mZHCZ0nhsVDB_dDavM/edit?usp=sharing
>
> Is it something in the configuration? Or a bug?
>
> Thomas
>
Order of spellcheck suggestions
Hi
I'm seeing different ordering on the spellcheck suggestions in cloud mode
when using spellcheck.extendedResults=false vs.
spellcheck.extendedResults=true.
Solr 8.5.2 in cloud mode with 2 nodes, 1 collection with numShards = 2 &
replicationFactor = 1, techproducts configset and example data:
$ curl '
http://localhost:8983/solr/techproducts/spell?q=power%20cort=false
'
"suggestion":["cord", "corp", "card"]}],
$ curl '
http://localhost:8983/solr/techproducts/spell?q=power%20cort=true
'
"suggestion":[{ "word":"corp", "freq":2}, { "word":"cord", "freq":1}, {
"word":"card", "freq":4}]}],
The correct order should be "corp" (LD: 1, freq: 2), "cord" (LD: 1, freq:
1) , "card" (LD: 2, freq: 4). In standalone mode, I get "corp", "cord",
"card" with extendedResults true or false.
The results are the same for the /spell and /browse request handlers in
that configset. I've put all combinations side by side in this spreadsheet:
https://docs.google.com/spreadsheets/d/1ym44TlbomXMCeoYpi_eOBmv6-mZHCZ0nhsVDB_dDavM/edit?usp=sharing
Is it something in the configuration? Or a bug?
Thomas
Re: Fw: TolerantUpdateProcessorFactory not functioning
If your XML or JSON can't be parsed, your content never makes it to the
update chain.
It looks like you're trying to index non-UTF-8 data. You can set the
encoding of your XML in the Content-Type header of your POST request.
-H 'Content-Type: text/xml; charset=GB18030'
JSON only allows UTF-8, UTF-16 or UTF-32.
Best,
Thomas
Op di 9 jun. 2020 07:11 schreef Hup Chen :
> Any idea?
> I still won't be able to get TolerantUpdateProcessorFactory working, solr
> exited at any error without any tolerance, any suggestions will be
> appreciated.
> curl "
> http://localhost:7070/solr/mycore/update?update.chain=tolerant-chain=100;
> -d @data.xml
>
>
>
>
>
>
> 100
> 400
> 1
>
>
>
> org.apache.solr.common.SolrException
> com.ctc.wstx.exc.WstxEOFException
>
> Unexpected EOF; was expecting a close tag for element
> field
> at [row,col {unknown-source}]: [1,8191]
> 400
>
>
>
>
>
> From: Hup Chen
> Sent: Friday, May 29, 2020 7:29 PM
> To: solr-user@lucene.apache.org
> Subject: TolerantUpdateProcessorFactory not functioning
>
> Hi,
>
> My solr indexing did not tolerate bad record but simply exited even I have
> configured TolerantUpdateProcessorFactory in solrconfig.xml.
> Please advise how could I get TolerantUpdateProcessorFactory to be
> working?
>
> solrconfig.xml:
>
>
>
> 100
>
>
>
>
> restarted solr before indexing:
> service solr stop
> service solr start
>
> curl "
> http://localhost:7070/solr/mycore/update?update.chain=tolerant-chain=100;
> -d @test.json
>
> The first record is a bad record in test.json, the rest were not indexed.
>
> {
> "responseHeader":{
> "errors":[{
> "type":"ADD",
> "id":"0007264097",
> "message":"ERROR: [doc=0007264097] Error adding field
> 'usedshipping'='' msg=empty String"}],
> "maxErrors":100,
> "status":400,
> "QTime":0},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Cannot parse provided JSON: Expected key,value separator ':':
> char=\",position=1240 AFTER='isbn\":\"4032171203\", \"sku\":\"\",
> \"title\":\"ãã³ãã¡ã¡ããã³ã \"author\"' BEFORE=':\"Sachiko
> OÃtomo\", ãã, \"ima'",
> "code":400}}
>
>
Atomic updates with add-distinct in Solr 7 cloud
Hi
I'm trying to do atomic updates with an 'add-distinct' modifier in a Solr 7
cloud. It seems to behave like an 'add' and I end up with double values in
my multiValued field. This only happens with multiple values for the field
in an update (cat:{"add-distinct":["a","b","d"]} exhibits this
problem, cat:{"add-distinct":"a"} doesn't). When running the same update
request with a single core, or a Solr 8 cloud, I get the expected result.
This is a minimal test case with Solr 7.7.3 in cloud mode, 2 nodes, a
collection with shard count 1 and replicationFactor 2, using the
techproducts configset.
$ curl -X POST -H 'Content-Type: text/json' '
http://localhost:8983/solr/techproducts/update?commit=true' --data-binary
'[{"id":123,cat:["a","b","c"]}]'
{
"responseHeader":{
"rf":2,
"status":0,
"QTime":75}}
$ curl -X POST -H 'Content-Type: text/json' '
http://localhost:8983/solr/techproducts/update?commit=true' --data-binary
'[{"id":123,cat:{"add-distinct":["a","b","d"]}}]'
{
"responseHeader":{
"rf":2,
"status":0,
"QTime":81}}
$ curl '
http://localhost:8983/solr/techproducts/select?q=id%3A123=true'
{
"response":{"numFound":1,"start":0,"docs":[
{
"id":"123",
"cat":["a",
"b",
"c",
"a",
"b",
"d"],
"_version_":1668919799351083008}]
}}
Is this a known issue or am I missing something here?
Kind regards
Thomas Corthals
Re-creating deleted Managed Stopwords lists results in error
Hi
I've run into an issue with creating a Managed Stopwords list that has the
same name as a previously deleted list. Going through the same flow with
Managed Synonyms doesn't result in this unexpected behaviour. Am I missing
something or did I discover a bug in Solr?
On a newly started solr with the techproducts core:
curl -X PUT -H 'Content-type:application/json' --data-binary
'{"class":"org.apache.solr.rest.schema.analysis.ManagedWordSetResource"}'
http://localhost:8983/solr/techproducts/schema/analysis/stopwords/testlist
curl -X DELETE
http://localhost:8983/solr/techproducts/schema/analysis/stopwords/testlist
curl http://localhost:8983/solr/admin/cores?action=RELOAD\=techproducts
curl -X PUT -H 'Content-type:application/json' --data-binary
'{"class":"org.apache.solr.rest.schema.analysis.ManagedWordSetResource"}'
http://localhost:8983/solr/techproducts/schema/analysis/stopwords/testlist
The second PUT request results in a status 500 with error
msg "java.util.LinkedHashMap cannot be cast to java.util.List".
Similar requests for synonyms work fine, no matter how many times I repeat
the CREATE/DELETE/RELOAD cycle:
curl -X PUT -H 'Content-type:application/json' --data-binary
'{"class":"org.apache.solr.rest.schema.analysis.ManagedSynonymGraphFilterFactory$SynonymManager"}'
http://localhost:8983/solr/techproducts/schema/analysis/synonyms/testmap
curl -X DELETE
http://localhost:8983/solr/techproducts/schema/analysis/synonyms/testmap
curl http://localhost:8983/solr/admin/cores?action=RELOAD\=techproducts
curl -X PUT -H 'Content-type:application/json' --data-binary
'{"class":"org.apache.solr.rest.schema.analysis.ManagedSynonymGraphFilterFactory$SynonymManager"}'
http://localhost:8983/solr/techproducts/schema/analysis/synonyms/testmap
Reloading after creating the Stopwords list but not after deleting it works
without error too on a fresh techproducts core (you'll have to remove the
directory from disk and create the core again after running the previous
commands).
curl -X PUT -H 'Content-type:application/json' --data-binary
'{"class":"org.apache.solr.rest.schema.analysis.ManagedWordSetResource"}'
http://localhost:8983/solr/techproducts/schema/analysis/stopwords/testlist
curl http://localhost:8983/solr/admin/cores?action=RELOAD\=techproducts
curl -X DELETE
http://localhost:8983/solr/techproducts/schema/analysis/stopwords/testlist
curl -X PUT -H 'Content-type:application/json' --data-binary
'{"class":"org.apache.solr.rest.schema.analysis.ManagedWordSetResource"}'
http://localhost:8983/solr/techproducts/schema/analysis/stopwords/testlist
And even curiouser, when doing a CREATE/DELETE for Stopwords, then a
CREATE/DELETE for Synonyms, and only then a RELOAD of the core, the cycle
can be completed twice. (Again, on a freshly created techproducts core.)
Only the third attempt to create a list results in an error. Synonyms can
still be created and deleted repeatedly after this.
curl -X PUT -H 'Content-type:application/json' --data-binary
'{"class":"org.apache.solr.rest.schema.analysis.ManagedWordSetResource"}'
http://localhost:8983/solr/techproducts/schema/analysis/stopwords/testlist
curl -X DELETE
http://localhost:8983/solr/techproducts/schema/analysis/stopwords/testlist
curl -X PUT -H 'Content-type:application/json' --data-binary
'{"class":"org.apache.solr.rest.schema.analysis.ManagedSynonymGraphFilterFactory$SynonymManager"}'
http://localhost:8983/solr/techproducts/schema/analysis/synonyms/testmap
curl -X DELETE
http://localhost:8983/solr/techproducts/schema/analysis/synonyms/testmap
curl http://localhost:8983/solr/admin/cores?action=RELOAD\=techproducts
curl -X PUT -H 'Content-type:application/json' --data-binary
'{"class":"org.apache.solr.rest.schema.analysis.ManagedWordSetResource"}'
http://localhost:8983/solr/techproducts/schema/analysis/stopwords/testlist
curl -X DELETE
http://localhost:8983/solr/techproducts/schema/analysis/stopwords/testlist
curl -X PUT -H 'Content-type:application/json' --data-binary
'{"class":"org.apache.solr.rest.schema.analysis.ManagedSynonymGraphFilterFactory$SynonymManager"}'
http://localhost:8983/solr/techproducts/schema/analysis/synonyms/testmap
curl -X DELETE
http://localhost:8983/solr/techproducts/schema/analysis/synonyms/testmap
curl http://localhost:8983/solr/admin/cores?action=RELOAD\=techproducts
curl -X PUT -H 'Content-type:application/json' --data-binary
'{"class":"org.apache.solr.rest.schema.analysis.ManagedWordSetResource"}'
http://localhost:8983/solr/techproducts/schema/analysis/stopwords/testlist
The same successes/errors occur when running each cycle against a different
core if the cores share the same configset.
Any ideas on what might be going wrong?
