Re: Compound Primary Keys
Thanks a lot. Appreciate the pointers about indexing engine vs database .
I ended up using concatenating the fields to generate a key.
On Wed, Apr 24, 2019 at 11:39 AM David Hastings <
hastings.recurs...@gmail.com> wrote:
> another thing to consider doing is just merge the two fields into the id
> value:
> "id": "USER_RECORD_12334",
> since its a string.
>
>
>
> On Wed, Apr 24, 2019 at 2:35 PM Gus Heck wrote:
>
> > Hi Vivek
> >
> > Solr is not a database, nor should one try to use it as such. You'll need
> > to adjust your thinking some in order to make good use of Solr. In Solr
> > there is normally an id field and it should be unique across EVERY
> document
> > in the entire collection. Thus there's no concept of a primary key,
> because
> > there are no tables. In some situations (streaming expressions for
> example)
> > you might want to use collections like tables, creating a collection per
> > data type, but there's no way to define uniqueness in terms of more than
> > one field within a collection. If your data comes from a database with
> > complex keys, concatenating the values to form the single unique ID is a
> > possibility. If you form keys that way of course you also want to retain
> > the values as individual fields. This duplication might seem odd from a
> > database perspective where one often works hard to normalize data, but
> for
> > search, denormalization is very common. The focus with search engines is
> > usually speed of retrieval rather than data correctness. Solr should
> serve
> > as an index into some other canonical source of truth for your data, and
> > that source of truth should be in charge of guaranteeing data
> correctness.
> >
> > Another alternative is to provide a field that denotes the type (table)
> for
> > the document (such as id_type in your example). In that case, all queries
> > looking for a specific object type as a result should add a filter (fq
> > parameter) to denote the "table" and you may want to store a db_id field
> to
> > correlate the data with a database if that's where it came from. When
> using
> > the field/filter strategy you tend to inflate the number of fields in the
> > index with some fields being sparsely populated and this can have some
> > performance implications, and furthermore if one "table" gets updated
> > frequently you wind up interfering with the caching for all data due to
> > frequent opening of new searchers. On the plus side such a strategy makes
> > it easier to query across multiple types simultaneously, so these
> > considerations should be balanced against your usage patterns,
> performance
> > needs, ease of management and ease of programming.
> >
> > Best,
> > Gus
> >
> > On Fri, Apr 19, 2019 at 2:10 PM Vivekanand Sahay
> > wrote:
> >
> > > Hello,
> > >
> > > I have a use case like below.
> > >
> > > USE CASE
> > > I have a document with fields like
> > >
> > > Id,
> > > Id_type,
> > > Field_1.
> > > Filed_2
> > >
> > > 2 sample messages will look like
> > >
> > > {
> > > "id": "12334",
> > > "id_type": "USER_RECORD",
> > > "field_1": null,
> > > "field_2": null
> > > }
> > >
> > >
> > > {
> > > "id": "31321",
> > > "id_type": "OWNER_RECORD",
> > > "field_1": null,
> > > "field_2": null
> > > }
> > >
> > >
> > > QUESTIONS
> > >
> > > I’d like to define the unique key as a compound key from fields id and
> > > id_type
> > >
> > > 1. Could someone give me an example of how to do this ? Or point to
> > the
> > > relevant section in the docs?
> > > 2. Is this the best way to define a compound primary key ? Is there
> a
> > > more efficient way ?
> > >
> > > Regards,
> > > Vivek
> > >
> >
> >
> > --
> > http://www.the111shift.com
> >
>
RE: Zk Status Error
Hey Shawn,
Thanks for the response. I was using 3.5.3-beta and after your suggestion I
tried 3.5.4-beta as well as the latest 3.4.* Zookeeper with the same issue.
Trying to execute the mntr command directly revealed the problem because I got
an error message that said that the mntr command was not whitelisted. Once I
added the mntr command to the whitelist everything is up and functional.
Thanks for the guidance.
Sadiki Latty
-Original Message-
From: Shawn Heisey [mailto:apa...@elyograg.org]
Sent: April 23, 2019 3:58 PM
To: solr-user@lucene.apache.org
Subject: Re: Zk Status Error
On 4/23/2019 12:14 PM, Sadiki Latty wrote:
> Here are the 2 errors in the Solr Logging section
>
> RequestHandlerBase java.lang.ArrayIndexOutOfBoundsException: 1
>
> "java.lang.ArrayIndexOutOfBoundsException: 1
>
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.monitorZookeeper(
> ZookeeperStatusHandler.java:185)
That line of code in Solr 7.7.1 is:
obj.put(line.split("\t")[0], line.split("\t")[1]);
The error is saying that the array created by the split function didn't have
two elements, so asking for the entry numbered 1 doesn't work.
Which means that the output Solr received from the ZK "mntr" command was not
what Solr expected.
What version of ZK do you have running your ZK ensemble? Is your ZK ensemble
working correctly? The ZK client version in Solr 7.7.1 is 3.4.13. If your
server version is different, maybe there was a change in the output from the
mntr command.
What happens if you issue the mntr command yourself directly?
Solr should, at the very least, detect possible problems with decoding the
response from ZK and display a more helpful message. If there was a change in
the command output, Solr should be resilient enough to handle it.
Thanks,
Shawn
Re: Compound Primary Keys
another thing to consider doing is just merge the two fields into the id
value:
"id": "USER_RECORD_12334",
since its a string.
On Wed, Apr 24, 2019 at 2:35 PM Gus Heck wrote:
> Hi Vivek
>
> Solr is not a database, nor should one try to use it as such. You'll need
> to adjust your thinking some in order to make good use of Solr. In Solr
> there is normally an id field and it should be unique across EVERY document
> in the entire collection. Thus there's no concept of a primary key, because
> there are no tables. In some situations (streaming expressions for example)
> you might want to use collections like tables, creating a collection per
> data type, but there's no way to define uniqueness in terms of more than
> one field within a collection. If your data comes from a database with
> complex keys, concatenating the values to form the single unique ID is a
> possibility. If you form keys that way of course you also want to retain
> the values as individual fields. This duplication might seem odd from a
> database perspective where one often works hard to normalize data, but for
> search, denormalization is very common. The focus with search engines is
> usually speed of retrieval rather than data correctness. Solr should serve
> as an index into some other canonical source of truth for your data, and
> that source of truth should be in charge of guaranteeing data correctness.
>
> Another alternative is to provide a field that denotes the type (table) for
> the document (such as id_type in your example). In that case, all queries
> looking for a specific object type as a result should add a filter (fq
> parameter) to denote the "table" and you may want to store a db_id field to
> correlate the data with a database if that's where it came from. When using
> the field/filter strategy you tend to inflate the number of fields in the
> index with some fields being sparsely populated and this can have some
> performance implications, and furthermore if one "table" gets updated
> frequently you wind up interfering with the caching for all data due to
> frequent opening of new searchers. On the plus side such a strategy makes
> it easier to query across multiple types simultaneously, so these
> considerations should be balanced against your usage patterns, performance
> needs, ease of management and ease of programming.
>
> Best,
> Gus
>
> On Fri, Apr 19, 2019 at 2:10 PM Vivekanand Sahay
> wrote:
>
> > Hello,
> >
> > I have a use case like below.
> >
> > USE CASE
> > I have a document with fields like
> >
> > Id,
> > Id_type,
> > Field_1.
> > Filed_2
> >
> > 2 sample messages will look like
> >
> > {
> > "id": "12334",
> > "id_type": "USER_RECORD",
> > "field_1": null,
> > "field_2": null
> > }
> >
> >
> > {
> > "id": "31321",
> > "id_type": "OWNER_RECORD",
> > "field_1": null,
> > "field_2": null
> > }
> >
> >
> > QUESTIONS
> >
> > I’d like to define the unique key as a compound key from fields id and
> > id_type
> >
> > 1. Could someone give me an example of how to do this ? Or point to
> the
> > relevant section in the docs?
> > 2. Is this the best way to define a compound primary key ? Is there a
> > more efficient way ?
> >
> > Regards,
> > Vivek
> >
>
>
> --
> http://www.the111shift.com
>
Re: Compound Primary Keys
Hi Vivek
Solr is not a database, nor should one try to use it as such. You'll need
to adjust your thinking some in order to make good use of Solr. In Solr
there is normally an id field and it should be unique across EVERY document
in the entire collection. Thus there's no concept of a primary key, because
there are no tables. In some situations (streaming expressions for example)
you might want to use collections like tables, creating a collection per
data type, but there's no way to define uniqueness in terms of more than
one field within a collection. If your data comes from a database with
complex keys, concatenating the values to form the single unique ID is a
possibility. If you form keys that way of course you also want to retain
the values as individual fields. This duplication might seem odd from a
database perspective where one often works hard to normalize data, but for
search, denormalization is very common. The focus with search engines is
usually speed of retrieval rather than data correctness. Solr should serve
as an index into some other canonical source of truth for your data, and
that source of truth should be in charge of guaranteeing data correctness.
Another alternative is to provide a field that denotes the type (table) for
the document (such as id_type in your example). In that case, all queries
looking for a specific object type as a result should add a filter (fq
parameter) to denote the "table" and you may want to store a db_id field to
correlate the data with a database if that's where it came from. When using
the field/filter strategy you tend to inflate the number of fields in the
index with some fields being sparsely populated and this can have some
performance implications, and furthermore if one "table" gets updated
frequently you wind up interfering with the caching for all data due to
frequent opening of new searchers. On the plus side such a strategy makes
it easier to query across multiple types simultaneously, so these
considerations should be balanced against your usage patterns, performance
needs, ease of management and ease of programming.
Best,
Gus
On Fri, Apr 19, 2019 at 2:10 PM Vivekanand Sahay
wrote:
> Hello,
>
> I have a use case like below.
>
> USE CASE
> I have a document with fields like
>
> Id,
> Id_type,
> Field_1.
> Filed_2
>
> 2 sample messages will look like
>
> {
> "id": "12334",
> "id_type": "USER_RECORD",
> "field_1": null,
> "field_2": null
> }
>
>
> {
> "id": "31321",
> "id_type": "OWNER_RECORD",
> "field_1": null,
> "field_2": null
> }
>
>
> QUESTIONS
>
> I’d like to define the unique key as a compound key from fields id and
> id_type
>
> 1. Could someone give me an example of how to do this ? Or point to the
> relevant section in the docs?
> 2. Is this the best way to define a compound primary key ? Is there a
> more efficient way ?
>
> Regards,
> Vivek
>
--
http://www.the111shift.com
Re: COLLECTION CREATE and CLUSTERSTATUS changes in SOLR 7.5.0
There’s some documentation in the ref guide, did you see it? Basically, if a replica is discovered by a solr instance by finding a “core.properties” file under SOLR_HOME, legacyCloud=true will try to reconstruct the ZooKeeper entry if it’s not there. This lead to lots of issues, and so it has been deprecated and should not be enabled. It should not affect collection _creation_ unless you’re manually creating directories under SOLR_HOME and/or using the core (NOT collection) admin API to create replicas, which you also should not do. IOW, the collection admin API CREATE should not be sensitive at all to this setting. Use the collections ADDREPLICA API to add replicas and you should be set. You can even create a collection with the special EMPTY nodeset that will allow you to precisely place each and every replica where you want it. Best, Erick > On Apr 24, 2019, at 9:29 AM, ramyogi wrote: > > What is legacyCloud properties does. Is there a document I could refer. Why > it impacts collection creation with rule based and index copy from one to > another. Replicas not registered how to fix without legacyCloud=true > settings. > > > > -- > Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: COLLECTION CREATE and CLUSTERSTATUS changes in SOLR 7.5.0
What is legacyCloud properties does. Is there a document I could refer. Why it impacts collection creation with rule based and index copy from one to another. Replicas not registered how to fix without legacyCloud=true settings. -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
RE: Sql entity processor sortedmapbackedcache out of memory issue
Hi Shawn, Mikhail Any suggestions/pointers for using zipper algorithm. I'm facing below error. Thanks and Regards, Srinivas Kashyap ** From: Srinivas Kashyap Sent: 12 April 2019 03:10 PM To: solr-user@lucene.apache.org Subject: RE: Sql entity processor sortedmapbackedcache out of memory issue Hi Shawn/Mikhail Khludnev, I was going through Jira https://issues.apache.org/jira/browse/SOLR-4799 and see, I can do my intended activity by specifying zipper. I tried doing it, however I'm getting error as below: Caused by: org.apache.solr.handler.dataimport.DataImportHandlerException: java.lang.IllegalArgumentException: expect increasing foreign keys for Relation CHILD_KEY=PARENT.PARENT_KEY got: QA-HQ008880,HQ011782 at org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:62) at org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:246) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:475) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:514) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:414) ... 5 more Caused by: java.lang.IllegalArgumentException: expect increasing foreign keys for Relation CHILD_KEY=PARENT.PARENT_KEY got: QA-HQ008880,HQ011782 at org.apache.solr.handler.dataimport.Zipper.supplyNextChild(Zipper.java:70) at org.apache.solr.handler.dataimport.EntityProcessorBase.getNext(EntityProcessorBase.java:126) at org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:74) at org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:243) Below is my dih config: Thanks and Regards, Srinivas Kashyap -Original Message- From: Shawn Heisey Sent: 09 April 2019 01:27 PM To: solr-user@lucene.apache.org Subject: Re: Sql entity processor sortedmapbackedcache out of memory issue On 4/8/2019 11:47 PM, Srinivas Kashyap wrote: > I'm using DIH to index the data and the structure of the DIH is like below > for solr core: > > > 16 child entities > > > During indexing, since the number of requests being made to database was > high(to process one document 17 queries) and was utilizing most of > connections of database thereby blocking our web application. If you have 17 entities, then one document will indeed take 17 queries. That's the nature of multiple DIH entities. > To tackle it, we implemented SORTEDMAPBACKEDCACHE with cacheImpl parameter to > reduce the number of requests to database. When you use SortedMapBackedCache on an entity, you are asking Solr to store the results of the entire query in memory, even if you don't need all of the results. If the database has a lot of rows, that's going to take a lot of memory. In your excerpt from the config, your inner entity doesn't have a WHERE clause. Which means that it's going to retrieve all of the rows of the ABC table for *EVERY* single entry in the DEF table. That's going to be exceptionally slow. Normally the SQL query on inner entities will have some kind of WHERE clause that limits the results to rows that match the entry from the outer entity. You may need to write a custom indexing program that runs separately from Solr, possibly on an entirely different server. That might be a lot more efficient than DIH. Thanks, Shawn DISCLAIMER: E-mails and attachments from Bamboo Rose, LLC are confidential. If you are not the intended recipient, please notify the sender immediately by replying to the e-mail, and then delete it without making copies or using it in any way. No representation is made that this email or any attachments are free of viruses. Virus scanning is recommended and is the responsibility of the recipient.
Re: CVE-2018-11802: Apache Solr authorization bug vulnerability disclosure
This fix has also been backported to Solr 6.6.6 for users who are stuck with Solr 6.x. (Sorry, I hadn't updated the issue and hence this was missed in the original mail.) On Wed, Apr 24, 2019 at 12:35 PM Noble Paul wrote: > > CVE-2018-11802: Apache Solr authorization bug disclosure > Severity: Important > Vendor: The Apache Software Foundation > Versions Affected: Apache Solr 7.6 or less > > Description: > jira ticket : https://issues.apache.org/jira/browse/SOLR-12514 > In apache Solr the cluster can be partitioned into multiple > collections and only a subset of nodes actually host any given > collection. However, if a node receives a request for a collection it > does not host, it proxies the request to a relevant node and serves > the request. Solr bypasses all authorization settings for such > requests. This affects all Solr versions that uses the default > authorization mechanism of Solr (RuleBasedAuthorizationPlugin) > > Mitigation: > A fix is provided in Solr 7.7 version and upwards. If you use Solr's > authorization mechanism, please upgrade to a version newer than Solr > 7.7. > > Credit: This issue was discovered by Mahesh Kumar Vasanthu Somashekar. > > - > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org >
Fwd: CVE-2018-11802: Apache Solr authorization bug vulnerability disclosure
Forwarding to solr-user list > Videresendt melding: > > Fra: Noble Paul > Emne: CVE-2018-11802: Apache Solr authorization bug vulnerability disclosure > Dato: 24. april 2019 kl. 09:04:55 CEST > Til: Lucene Dev , java-u...@lucene.apache.org, > secur...@apache.org, oss-secur...@lists.openwall.com > Svar til: java-u...@lucene.apache.org > > CVE-2018-11802: Apache Solr authorization bug disclosure > Severity: Important > Vendor: The Apache Software Foundation > Versions Affected: Apache Solr 7.6 or less > > Description: > jira ticket : https://issues.apache.org/jira/browse/SOLR-12514 > In apache Solr the cluster can be partitioned into multiple > collections and only a subset of nodes actually host any given > collection. However, if a node receives a request for a collection it > does not host, it proxies the request to a relevant node and serves > the request. Solr bypasses all authorization settings for such > requests. This affects all Solr versions that uses the default > authorization mechanism of Solr (RuleBasedAuthorizationPlugin) > > Mitigation: > A fix is provided in Solr 7.7 version and upwards. If you use Solr's > authorization mechanism, please upgrade to a version newer than Solr > 7.7. > > Credit: This issue was discovered by Mahesh Kumar Vasanthu Somashekar. > > - > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org >
JSON facet API - can't reference 'val' field
Hi,
Is there any way to reference the 'val' value of a bucket in the JSON
facet API? I have a set of records that all have collection tags. I want
to facet on those collections and sort them by a function that uses the
number of search documents in that collection and the total number of
index documents in that collection. The first is just 'count', and the
second is 'docfreq(collections_sm,val)', but I can't seem to access the
'val' value. I can't get that value from the document fields as the
collection tag field is multivalued and some collections overlap. Any ideas?
Example query:
q=test={collections: { type: terms, field: collections_sm}}
Response:
..."facets":{
"count":78,
"collections":{
"buckets":[{
"val":"Ephemera",
"count":10},
{
"val":"Educational Ephemera",
"count":5}, ...
Query I want to get working:
q=test={
collections:{
type: terms,
field: collections_sm,
sort: {s: asc},
facet:{
s:"div(docfreq(collections_sm,val),count)"
}
}
}
Thanks,
Mel
Re: Learning to Rank Feature creation in python
Hi Ashis, Short answer: No, i don't think it's possible. I'm considering as well extending solr to allow plugging in features from outside, but it will require time because at the moment the features can see only the current document processed, while to do that ideally you want to process in one shot all the documents that you are reranking... In your specific case, could you index the docembedding with the document, send the query embedding as external feature information (efi) and implement a Java feature that combines them? On Wed, Apr 24, 2019, 09:12 Ashis Tripathy wrote: > Hi , > > Hope you are doing well!!! > > I am currently trying to implement Learn To Rank in SOLR 7.5. I have gone > through the blogs and documentation page to follow the steps. However the > current process looks like i need to write SOLR query in a json file to > upload the same to Feature Store. > > But the problem is , some of the features which I want to create can't be > created using SOLR query syntax. For example: Document embeddings and query > embeddings using Doc2Vec model in python. > > Is there any way i can generate the features outside SOLR by passing the > query and the top-K result set to a method written in python and then > rerank the results using the trained model. > > Any help will be highly appreciated as this thing is blocking me completely > from going ahead. > > few useful links which i found: > https://github.com/airalcorn2/Solr-LTR > https://lucene.apache.org/solr/guide/7_5/learning-to-rank.html > > please let me know in case you need any other details about the issue. > > Regards > Ashis >
Learning to Rank Feature creation in python
Hi , Hope you are doing well!!! I am currently trying to implement Learn To Rank in SOLR 7.5. I have gone through the blogs and documentation page to follow the steps. However the current process looks like i need to write SOLR query in a json file to upload the same to Feature Store. But the problem is , some of the features which I want to create can't be created using SOLR query syntax. For example: Document embeddings and query embeddings using Doc2Vec model in python. Is there any way i can generate the features outside SOLR by passing the query and the top-K result set to a method written in python and then rerank the results using the trained model. Any help will be highly appreciated as this thing is blocking me completely from going ahead. few useful links which i found: https://github.com/airalcorn2/Solr-LTR https://lucene.apache.org/solr/guide/7_5/learning-to-rank.html please let me know in case you need any other details about the issue. Regards Ashis
Intermittent error 401 with JSON Facet query to retrieve count all collections
Hi,
I am using the below JSON Facet to retrieve the count of all the different
collections in one query.
https://localhost:8983/solr/collection1/select?q=testing=https://localhost:8983/solr/collection1,https://localhost:8983/solr/collection2,https://localhost:8983/solr/collection3,https://localhost:8983/solr/collection4,https://localhost:8983/solr/collection5,https://localhost:8983/solr/collection6=0={categories
:
{type : terms,field : content_type,limit : 100}}
Previously, in Solr 7.6 and Solr 7.7, this query can work correctly and we
are able to produce the correct output.
{
"responseHeader":
{ "zkConnected":true, "status":0, "QTime":24}
,
"response":
{"numFound":41200,"start":0,"maxScore":12.993215,"docs":[] }
,
"facets":{
"count":41200,
"categories":{
"buckets":[
{ "val":"collection1", "count":26213}
,
{ "val":"collection2", "count":12075}
,
{ "val":"collection3", "count":1947}
,
{ "val":"collection4", "count":850}
,
{ "val":"collection5", "count":111}
,
{ "val":"collection6", "count":4}
]}}}
However, in the new Solr 8.0.0, this query can only work occasionally. Most
of the time, we will get the following error of 'Error 401 require
authentication':
{
"responseHeader":
{ "zkConnected":true, "status":401, "QTime":11}
,
"error":{
"metadata":[
"error-class","org.apache.solr.client.solrj.impl.Http2SolrClient$RemoteSolrException",
"root-error-class","org.apache.solr.client.solrj.impl.Http2SolrClient$RemoteSolrException"],
"msg":"Error from server at null: Expected mime type
application/octet-stream but got text/html. \n\n\nError 401 require
authentication\n\nHTTP ERROR 401\nProblem
accessing /solr/collection6/select. Reason:\nrequire
authentication\n\n\n",
"code":401}}
This issue does not occur in Solr 7.6 and Solr 7.7, even though I have set
up the same authentication for all the versions.
What could be the issue that causes this?
Below is the format of my security.json:
{
"authentication":
{"blockUnknown": true,"class":"solr.BasicAuthPlugin",
"credentials":
{"user1":"hyHXXuJSqcZdNgdSTGUvrQZRpqrYFUQ2ffmlWQ4GUTk=
E0w3/2FD+rlxulbPm2G7i9HZqT+2gMBzcyJCcGcMWwA="}
},
"authorization":
{"class":"solr.RuleBasedAuthorizationPlugin","user-role":
{"user1":"admin"}
,
"permissions":[
{"name":"security-edit", "role":"admin"}
]
}}
Regards,
Edwin
On Mon, 22 Apr 2019 at 09:37, Zheng Lin Edwin Yeo
wrote:
> Hi,
>
> Anyone has experienced this or have any insights of this?
>
> Regards,
> Edwin
>
> On Thu, 18 Apr 2019 at 18:04, Zheng Lin Edwin Yeo
> wrote:
>
>> Is there possibility that this could be a bug in the new Solr 8.0.0?
>>
>> Since I do not face the issue in the earlier version, and I have not
>> changed any configuration in this new version. My data in Solr 8.0.0 is
>> freshly re-index directly in Solr 8.0.0, not upgraded from earlier version.
>>
>> Regards,
>> Edwin
>>
>> On Thu, 18 Apr 2019 at 10:10, Zheng Lin Edwin Yeo
>> wrote:
>>
>>> Hi Jason,
>>>
>>> The same problem still persist after restarting my Solr nodes. The only
>>> time the problem didn't occur is when I disabled the basic authentication.
>>>
>>> I have tried with a few "/select?q=*:*", and they do not exhibit the
>>> same problem. Even the similar query with only 1 shard does not have the
>>> problem.
>>>
>>>
>>> https://localhost:8983/solr/collection1/select?q=testing=https://localhost:8983/solr/collection1=0={categories
>>> : {type : terms,field : content_type,limit : 100}}
>>>
>>>
>>> It is only when there are 2 or more shards, that the problem occur.
>>>
>>>
>>> https://localhost:8983/solr/collection1/select?q=testing=https://localhost:8983/solr/collection1,https://localhost:8983/solr/collection2=0={categories
>>> : {type : terms,field : content_type,limit : 100}}
>>>
>>>
>>> Regards,
>>> Edwin
>>>
>>>
>>> On Thu, 18 Apr 2019 at 01:15, Jason Gerlowski
>>> wrote:
>>>
Agreed, I'd be surprised if this behavior was specific to JSON
Faceting. Though I'm surprised it's happening at all, so...
Anyway, that's easy for you to test though. Try a few "/select?q=*:*"
queries and see whether they also exhibits this behavior. One other
question: does the behavior persist after restarting your Solr nodes?
Good luck,
Jason
On Wed, Apr 17, 2019 at 4:05 AM Zheng Lin Edwin Yeo
wrote:
>
> Hi,
>
> For your info, I have enabled basic authentication and SSL in all the
3
> versions, and I'm not sure if the issue is more on the authentication
side
> instead of the JSON Facet query?
>
> Regards,
> Edwin
>
> On Wed, 17 Apr 2019 at 06:54, Zheng Lin Edwin Yeo <
edwinye...@gmail.com>
> wrote:
>
> > Hi Jason,
> >
> > Yes, that is correct.
> >
