t; To: solr-user@lucene.apache.org
> Subject: Re: Clarification on term facet method dvhash
>
> Correction!: wrt "dvhash" and numeric types, it looks like I had it exactly
> backwards! single-valued numeric types _do_ use (even default to) "dvhash"
> ... sorry a
: solr-user@lucene.apache.org
Subject: Re: Clarification on term facet method dvhash
Correction!: wrt "dvhash" and numeric types, it looks like I had it exactly
backwards! single-valued numeric types _do_ use (even default to) "dvhash"
... sorry about that! I stand by the
;smart" at the
> moment, but rather must be specified explicitly:
>
> https://github.com/apache/lucene-solr/blob/6ff4a9b395a68d9b0d9e259537e3f5daf0278d51/solr/core/src/java/org/apache/solr/search/facet/FacetField.java#L124-L128
>
> The code snippet above indicates some other
f4a9b395a68d9b0d9e259537e3f5daf0278d51/solr/core/src/java/org/apache/solr/search/facet/FacetField.java#L124-L128
The code snippet above indicates some other restrictions that you're
probably already aware of (doesn't work with prefixes or mincount==0, or
for multi-valued or numeric types)
Hello,
I’m using Solr 8.4. Very excited about performance improvements in 8.8:
http://joelsolr.blogspot.com/2021/01/optimizations-coming-to-solr.html
As I understand the main determinator of performance and RAM usage of a terms
facet is cardinality of the field in whole collection, but not the
ssibly-relevant discussion can
be found in the following thread:
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/202006.mbox/%3CCAF%3DheHFd6GBABzKzDQPTfpYUUQJXxYwue4OC86QOm_AR0X3_ZQ%40mail.gmail.com%3E
On Thu, Jan 28, 2021 at 7:25 PM Jae Joo wrote:
> I am wondering that the performanc
I am wondering that the performance of facet of DocValued SortableText
Field is slower than non Docvalued String Field.
Does anyone know why?
Thanks,
Jae
ry to solr-cloud with following
> parameters
>
> "q":"organization:abc",
> "facet.limit":"10",
> "facet.field":"doc_id",
> "indent":"on",
> "fl":"archive_id",
following
parameters
"q":"organization:abc",
"facet.limit":"10",
"facet.field":"doc_id",
"indent":"on",
"fl":"archive_id",
"facet.mincount":"2",
&q
Hi everyone,
Last day I was comparing term+range facet counts from two different collections
having exact same data and schema. Only difference is one collection has 2
shards, the other 1. After searching about this I came upon an article:
medium.com
My results were like this:
Counts from
Radu Gheorghe
wrote:
>
> > On 3 Dec 2020, at 20:18, Shawn Heisey wrote:
> >
> > On 12/3/2020 9:55 AM, Jae Joo wrote:
> >> Is there any way to apply facet to the partial search result?
> >> For ex, we have 10m return by "dog" and like to apply facet to
> On 3 Dec 2020, at 20:18, Shawn Heisey wrote:
>
> On 12/3/2020 9:55 AM, Jae Joo wrote:
>> Is there any way to apply facet to the partial search result?
>> For ex, we have 10m return by "dog" and like to apply facet to first 10K.
>> Possible?
>
>
On 12/3/2020 9:55 AM, Jae Joo wrote:
Is there any way to apply facet to the partial search result?
For ex, we have 10m return by "dog" and like to apply facet to first 10K.
Possible?
The point of facets is to provide accurate numbers.
What would it mean to only apply to the firs
Is there any way to apply facet to the partial search result?
For ex, we have 10m return by "dog" and like to apply facet to first 10K.
Possible?
Jae
Hi Shivram,
I think the short answer is "no". At least, not without sub-classing
some of the JSON-Facet classes in SolrJ.
But it's hard for me to understand your particular concern without
seeing a concrete example. If you provide an example (maybe in the
form of a JUnit test
class.
> basically as *queryResponse.getJsonFacetingResponse() -> returns
> *NestableJsonFacet
> object.
>
> But I have noticed it does not maintain the facet-query order in which it
> was given in *facet.json.*
> *Direct queries to solr do maintain that order, but not after it
Hi folks,
Doing some faceted queries using 'facet.json' param and SolrJ, the results
of which I am processing using SolrJ NestableJsonFacet class.
basically as *queryResponse.getJsonFacetingResponse() -> returns
*NestableJsonFacet
object.
But I have noticed it does not maintain th
order to make it a valid JSON string.
: Date: Mon, 13 Jul 2020 04:03:50 +
: From: Mohamed Sirajudeen Mayitti Ahamed Pillai
:
: Reply-To: solr-user@lucene.apache.org
: To: "solr-user@lucene.apache.org"
: Subject: JSON Facet with local parameter
:
:
lucene.apache.org"
: Subject: JSON Facet with local parameter
:
: Is it possible to refer local parameter for Range JSON Facet’s star/end/gap
inputs ?
:
:
: I am trying something like below, but it is now working.
:
http://server:8983/solr/kfl/select?arrivalRange=NOW/DAY-10DAYS&json.f
tadata":
["error-class","org.apache.solr.common.SolrException","root-error-class","org.apache.solr.common.SolrException"],"msg":
"Can't parse value $arrivalRange for field: pdp_activation_date_dt","code":
400}
How to instruct Solr JSON Facet to reference another parameter that is added to
the search request ?
queryResultCache doesn’t really help with faceting, even if it’s hit for the
main query.
That cache only stores a subset of the hits, and to facet properly you need
the entire result set….
> On Jun 17, 2020, at 12:47 PM, James Bodkin
> wrote:
>
> We've noticed that the f
we require the results in real-time for customers searching on our website,
the later QTime of 1000-1200ms is too slow for us to be able to use.
Our facet queries change as the customer selects different search criteria, and
hence the possible number of potential queries makes it very difficult
least
for "legacy" facets or whatever -- not sure about "enum" method in
JSON facets).
Even where "docValues=true" arguably does make faceting "faster", the
main benefit is that the "uninverted" data structures are serialized
on disk, so you'
do any harm either.
That said, I frankly
don’t know how that interacts with facet.method=enum.
As far as speed… yeah, you’re in the edge cases. All things being equal,
stuffing these into the
filterCache is the fastest way to facet if you have the memory. I’ve seen very
few installations
where
s
"no values"). So that explains why facet.method=enum no longer works.
I was going to suggest that you might not want to set indexed=false on
the docValues facet fields anyway, since the indexed values are still
used for facet refinement (assuming your index is distribute
ote:
> I strongly recommend setting indexed=true on a field you facet on for the
> purposes of efficient refinement (fq=field:value). But it strictly isn't
> required, as you have discovered.
>
> ~ David
>
>
> On Wed, Jun 17, 2020 at 9:02 AM Michael Gibney
> wrot
I strongly recommend setting indexed=true on a field you facet on for the
purposes of efficient refinement (fq=field:value). But it strictly isn't
required, as you have discovered.
~ David
On Wed, Jun 17, 2020 at 9:02 AM Michael Gibney
wrote:
> facet.method=enum works by executing
docValues facet fields anyway, since the indexed values are still
used for facet refinement (assuming your index is distributed).
What's the number of unique values in the relevant fields? If it's low
enough, setting docValues=false and indexed=true and using
facet.method=enum (with
arts of the index to be read. In this case,
probably just facet on all the fields you care about. I'd add sorting too
if you sort on different fields.
The *:* query without facets or sorting does virtually nothing due to some
special handling...
On Tue, Jun 16, 2020, 10:4
Ok, I see the disconnect... Necessary parts if the index are read from disk
lazily. So your newSearcher or firstSearcher query needs to do whatever
operation causes the relevant parts of the index to be read. In this case,
probably just facet on all the fields you care about. I'd add sortin
I saw
in NewRelic however it is probably trying to read the docValues from disk. How
can we use the autowarming to improve this?
>
> For example, I've run the following queries in sequence and each query
has a first-execution penalty.
>
> Query 1
is probably trying to read the docValues from
> disk. How can we use the autowarming to improve this?
>
> For example, I've run the following queries in sequence and each query has a
> first-execution penalty.
>
> Query 1:
>
> q=*:*
> facet=true
> facet.fie
ry has a
first-execution penalty.
Query 1:
q=*:*
facet=true
facet.field=D_DepartureAirport
facet.field=D_Destination
facet.limit=-1
rows=0
Query 2:
q=*:*
fq=D_DepartureAirport:(2660)
facet=true
facet.field=D_Destination
facet.limit=-1
rows=0
Query 3:
q=*:*
fq=D_DepartureAirport:(2
fired when Solr starts, the theory being that there’s no
cache autowarming available when Solr fist powers up. Usually, people don’t
bother with firstSearcher or just make it the same as newSearcher. Note that a
query doesn’t have to be “real” at all. You can just add all the facet fields
R-13227 for instance.
Two options you might try:
1> copyField to a string field and facet on that (won’t work, of course,
for any kind of interval/range facet)
2> use the deprecated Trie field instead. You could use the copyField to a
Trie field for this too.
Best,
Erick
This works: &f.interests.facet.matches=hockey|soccer
--
Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
for faceting,
see: https://issues.apache.org/jira/browse/SOLR-13227 for instance.
Two options you might try:
1> copyField to a string field and facet on that (won’t work, of course,
for any kind of interval/range facet)
2> use the deprecated Trie field instead. You could use the copy
There’s a lot of confusion about using points-based fields for faceting, see:
https://issues.apache.org/jira/browse/SOLR-13227 for instance.
Two options you might try:
1> copyField to a string field and facet on that (won’t work, of course, for
any kind of interval/range facet)
2> u
We’ve been running a load test against our index and have noticed that the
facet queries are significantly slower than we would like.
Currently these types of queries are taking several seconds to execute and are
wondering if it would be possible to speed these up.
Repeating the same query over
ml#child-childdoctransformerfactory
https://lucene.apache.org/solr/guide/8_5/transforming-result-documents.html#subquery
: Date: Mon, 20 Apr 2020 04:37:06 -0700 (MST)
: From: Venu
: Reply-To: solr-user@lucene.apache.org
: To: solr-user@lucene.apache.org
: Subject: Re: Solr facet order same as
Probably I haven't framed my question properly.
Consider the schema with the fields - id, sku, fc_id, group_id
The same SKU can be part of multiple documents with different fc_id and
group_id.
For a given search query, multiple documents having the same SKU will be
returned. Is there any way I ca
ordered in the same sort order as the docs?
It’s much worse with multivalued fields, since a single doc can
contribute to more than one facet.
Best,
Erick
> On Apr 20, 2020, at 5:53 AM, Venu wrote:
>
> Hi
> For a given query and sort order, Solr returns the results(ordered based on
Hi
For a given query and sort order, Solr returns the results(ordered based on
score and sort order) set along with facets(ordered in descending order of
buckets counts)
Is there any way to get the facets also in the same order as results/docs? I
tried with json facet, but I am not able to make
"count":603},
{
"val":"2019-01-08T01:08:58Z",
"count":484},
.
.
.
.
"val":"2019-01-26T06:30:33Z",
"count":3}]}}}
There is 2660 buckets (which is the result of my fix) while
limit:-1,
> numBuckets:true,
> missing:false,
> refine:true,
>
Guys?
Artur Rudenko
-Original Message-
From: Rudenko, Artur
Sent: Saturday, February 15, 2020 12:50 PM
To: solr-user@lucene.apache.org
Subject: RE: Possible performance bug - JSON facet - numBuckets:true
Promoting my question
Thanks,
Artur Rudenko
From: Rudenko, Artur
Sent
Hi, All
Is facet.threads available on JSON Facet? If it's available on JSONFacet, how
do I specify on request parameters?
I'm using facet.threads on JSON Facet like below. I can't confirm any
performance difference before-and-after specifying facet.threads=-1
localhost:8983/s
/>
>
> dest="Party_Relation_Tiered"/>
>
> dest="Party_Relation_Tiered"/>
>
> dest="Party_Relation_Tiered"/>
>
16:33
To: solr-user@lucene.apache.org
Subject: Re: Solr datePointField facet
Hi Srinivas,
But still facing the same error.
The same error? Can you please post the facet query? Please post (part of)
your schema too.
On Tue, 25 Feb 2020 at 16:00, Srinivas
Hi Srinivas,
But still facing the same error.
The same error? Can you please post the facet query? Please post (part of)
your schema too.
On Tue, 25 Feb 2020 at 16:00, Srinivas Kashyap
wrote:
> Hi all,
>
> I have a date field in my schema and I'm trying to facet on that field
Hi all,
I have a date field in my schema and I'm trying to facet on that field and
getting below error:
This field I'm copying to text field(copyfield) as well.
Error:
Can't facet on a PointField without docValues
I tried adding like below:
And after the changes, I d
Promoting my question
Thanks,
Artur Rudenko
From: Rudenko, Artur
Sent: Wednesday, February 12, 2020 9:48 PM
To: solr-user@lucene.apache.org
Subject: Possible performance bug - JSON facet - numBuckets:true
Hello everyone,
I'm am currently investigating a performance issue in our environmen
numBuckets:true,
missing:false,
refine:true,
facet:{
. I'm trying to sum the same
> field in a frange subquery and I don't know how.
>
>
> /select?defType=edismax&q=*:*&fq={!geofilt}&fl=totalResultsUsers,_dist_:geodist(),score&sort=geodist()
>
> desc&facet=true&rows=0&facet.limit=-1&facet.minco
p;fl=totalResultsUsers,_dist_:geodist(),score&sort=geodist()
desc&facet=true&rows=0&facet.limit=-1&facet.mincount=1&facet.sort=value&stats=true&distanceUnits=miles&wt=json&fq=dId:193&sfield=Coordinates&pt=40.243919,-74.753489&d=5&stats.field=
s I know.
> >>>
> >>> On 12/12/2019 11:40, Joel Bernstein wrote:
> >>>> There is a field type in the schema called pdate:
> >>>>
> >>>>
> >>>>
> >>>> This should work for you.
> >>>>
&
ma called pdate:
This should work for you.
The timeseries Streaming Expression uses the JSON facet API for range
faceting and works really well.
Joel Bernstein
http://joelsolr.blogspot.com/
On Thu, Dec 12, 2019 at 6:28 AM Mel Mason
wrote:
Hi,
I'm trying to have a range face
represent that as far as I know.
>>
>> On 12/12/2019 11:40, Joel Bernstein wrote:
>> > There is a field type in the schema called pdate:
>> >
>> >
>> >
>> > This should work for you.
>> >
>> > The timeseries Streaming Expr
[2000-05-01 TO 2019-06-02].
> DatePointFields can't represent that as far as I know.
>
> On 12/12/2019 11:40, Joel Bernstein wrote:
> > There is a field type in the schema called pdate:
> >
> >
> >
> > This should work for you.
> >
> > The t
uses the JSON facet API for range
faceting and works really well.
Joel Bernstein
http://joelsolr.blogspot.com/
On Thu, Dec 12, 2019 at 6:28 AM Mel Mason
wrote:
Hi,
I'm trying to have a range facet on a field of type solr.DateRangeField.
As far as I can tell, this isn't possible
There is a field type in the schema called pdate:
This should work for you.
The timeseries Streaming Expression uses the JSON facet API for range
faceting and works really well.
Joel Bernstein
http://joelsolr.blogspot.com/
On Thu, Dec 12, 2019 at 6:28 AM Mel Mason
wrote:
> Hi,
>
Currently, it is not supported yet. Related JIRA -
https://issues.apache.org/jira/browse/SOLR-10567
Regards,
Munendra S N
On Thu, Dec 12, 2019 at 4:58 PM Mel Mason
wrote:
> Hi,
>
> I'm trying to have a range facet on a field of type solr.DateRangeField.
> As far as I can
Hi,
I'm trying to have a range facet on a field of type solr.DateRangeField.
As far as I can tell, this isn't possible with JSONFacet, only with the
old facet system - a quick google turns up several other people with the
same problem. When using JSONFacet I get problems with th
How are you getting the word counts? Do you have a field in the doc where you
store it? If so, either use “interval facets” or “facet queries”, either one
should give you what you want.
Your particular example would also work with “range faceting” since the buckets
are identically sized.
See
-750 words: 4554 results
750-1000 words: 9854 results
1000-1250 words: 3439 results
1250-1500 words: 38 results
Solr's faceting API docs assume that the facet buckets are known in advance,
but this isn't possible for numeric fields because the lower and upper
buckets depend on the search re
-750 words: 4554 results
750-1000 words: 9854 results
1000-1250 words: 3439 results
1250-1500 words: 38 results
Solr's faceting API docs assume that the facet buckets are known in advance,
but this isn't possible for numeric fields because the lower and upper
buckets depend on the search re
Are you querying across multiple collections? In that case you have to add the
field to all those collections. You have not shown us your facet query.
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
> 11. okt. 2019 kl. 22:37 skrev Joe Obernberger :
>
> Hi
Hello Shawn, thanks for reply. The results that come back are correct, but are
we implementing the query correctly to filter by a selected facet? When I say
wrong, it's more about the design/use of Facets in the Query. Is it proper to
do fq=Tags:Retirement? Is using a Multivalued field co
On 10/14/2019 3:25 PM, Moyer, Brett wrote:
Hello, looking for some advice, I have the suspicion we are doing Facets all wrong. We
host financial information and recently "tagged" our pages with appropriate
Facets. We have built a Flat design. Are we going at it the wrong way?
In Solr we have a
Hello, looking for some advice, I have the suspicion we are doing Facets all
wrong. We host financial information and recently "tagged" our pages with
appropriate Facets. We have built a Flat design. Are we going at it the wrong
way?
In Solr we have a "Tags" field, based on some magic we tagged
ue}}'
http://miranda:9100/solr/UNCLASS_2019_8_5_36/schema
It returned success. In the UI, when I examine the schema, it shows up
but does not list 'schema' with the check-boxes for Indexed/DocValues
etc.. It only lists Properties for FaceCluster. Other plong fields
that were a
Raised https://issues.apache.org/jira/browse/SOLR-13715
On Fri, Aug 23, 2019 at 12:20 PM harjagsbby
wrote:
> I dint quite get your question.Our Solr collection under contention is not
> shareded. Data being joint is collocated.INfact multithreaded facet help
> our
> performan
I dint quite get your question.Our Solr collection under contention is not
shareded. Data being joint is collocated.INfact multithreaded facet help our
performance.
Afer debugging more solr 7 calls JoinQParserPlugin createWeight is called by
each thread of multithreaded facets but not in solr 6
readed facets and joins.
>
> Can anyone explain the semaphore implemenattion here. What would be
> scenario
> when this can go below 0. I can clearly see each thread of multithreaded
> facet trying to close the core.
>
> Every Thread of facet tries to call createWeigh
scenario
when this can go below 0. I can clearly see each thread of multithreaded
facet trying to close the core.
Every Thread of facet tries to call createWeight of JoinQParserPlugin and
attaches closeHooks which getscalled from SolrRequestInfo.clearRequestInfo()
.
if (fromRef != null) {
scenario
when this can go below 0. I can clearly see each thread of multithreaded
facet trying to close the core.
Every Thread of facet tries to call createWeight of JoinQParserPlugin and
attaches closeHooks which getscalled from SolrRequestInfo.clearRequestInfo()
.
if (fromRef != null) {
:promo-opera-test-1000_promo-opera-test-1000**&enableManagedResourceRange=true&facet=true&facet.mincount=1&**facet.threads=32**&facet.field=dynamiccategory_facet&facet.recommend.maxfacets=30&facet.recommend.debug=true&sort=ratingandreviewsort+desc&qt=/promo&timeAllowe
2019-07-09 17:37:30.053 INFO
(facetExecutor-67-thread-22-processing-n:127.0.0.1:8983_solr
x:products_comp-v1_shard1_replica_n21 c:products_comp-v1 s:shard1
r:core_node22) [ ] o.a.s.c.SolrCore [promotion_rules-v1_shard1_replica_n1]
**CLOSING SolrCore org.apache.solr.core.SolrCore**@44de0f89
2019
On 7/8/2019 12:00 PM, Midas A wrote:
Number of Docs :50+ docs
Index Size: 300 GB
RAM: 256 GB
JVM: 32 GB
Half a million documents producing an index size of 300GB suggests
*very* large documents. That typically produces an index with fields
that have very high cardinality, due to text tok
On 7/8/2019 3:08 AM, Midas A wrote:
I have enabled docvalues on facet field but query is still taking time.
How i can improve the Query time .
docValues="true" multiValued="true" termVectors="true" />
*Query: *
There's very little information here
Hi
How i can know whether DocValues are getting used or not ?
Please help me here .
On Mon, Jul 8, 2019 at 2:38 PM Midas A wrote:
> Hi ,
>
> I have enabled docvalues on facet field but query is still taking time.
>
> How i can improve the Query time .
> docValues="
Hi ,
I have enabled docvalues on facet field but query is still taking time.
How i can improve the Query time .
*Query: *
http://X.X.X.X:
/solr/search/select?df=ttl&ps=0&hl=true&fl=id,upt&f.ind.mincount=1&hl.usePhraseHighlighter=true&f.pref.mincount=1&q.op=OR&a
Hello,
I have a collection containing a field called text defined as below in the
schema.xml file:
Here is an example of text: "pam_unix(cron:session): session closed for user
root"
I want to know the number of documents containing the expression "session
closed".
Below the request I use
Hi,
I am trying to use JSON faceting in SOLR 7.3 along with grouping documents and
noticed that group.facet=true is not working with json.facet but it works with
flat faceting.
Query Format I used:
http://localhost:8983/solr/Collection/select?q=*:*&facet=true&facet.mincount=2&am
/2019 7:54 AM, Claudio R wrote:
> When I try this request to get facet of fields: fieldA, fieldB and fieldC on
> multicore search, I get error:
>
> http://localhost:8983/solr/core1/select?q=*:*&shards=localhost:8983/solr/core1,localhost:8983/solr/core2&fl=*,[shard]&facet=t
On 6/14/2019 7:54 AM, Claudio R wrote:
When I try this request to get facet of fields: fieldA, fieldB and fieldC on
multicore search, I get error:
http://localhost:8983/solr/core1/select?q=*:*&shards=localhost:8983/solr/core1,localhost:8983/solr/core2&fl=*,[shard]&facet=true&fa
Hi,
I am using Solr 6.6.0 in mode standalone with 2 cores.
The first core has the schema:
id
fieldA
fieldB
The second core has the schema:
id
fieldA
fieldC
When I try this request to get facet of fields: fieldA, fieldB and fieldC on
multicore search, I get error:
http://localhost:8983/solr
m:Jan Høydahl
> Sent: Thursday 13th June 2019 0:17
> To: solr-user
> Subject: Re: Different facet count between 7.7.1 and 8.1.1
>
> Can you reproduce it from a clean 7.7.1 install? I mean, index N docs and
> then run the facet query? Is it a distributed query or a single shar
Can you reproduce it from a clean 7.7.1 install? I mean, index N docs and then
run the facet query? Is it a distributed query or a single shard? Does an
"optimize" change anything? Is this DocValues strings?
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Hello again,
We found another oddity when upgrading to Solr 8. For a *:* query, the facet
counts for a simple string field do not match at all between these versions.
Solr 7.7.1 gives less or zero counts where as for 8 we see the correct counts.
So something seems fixed for a bug that i was
Hi Jason,
Yes. I am using the latest Solr 8.1.1.
The query which I'm using is the JSON Facet query which I faced the error
initially.
Regards,
Edwin
On Tue, 4 Jun 2019 at 20:15, Jason Gerlowski wrote:
> Hi Edwin,
>
> Thanks for the additional datapoint. It seemed to work
Hi Edwin,
Thanks for the additional datapoint. It seemed to work for me, but we
don't really understand the problem yet, so maybe it's not a solid
work around like I'd hoped. I'm curious to hear whether it works for
Colvin.
To double check though: forwardCredentials is only supported in Solr >
Hi Jason,
Thanks for your reply.
I have tried to add the "forwardCredentials": true in the security.json,
but I still get the same error.
Regards,
Edwin
On Mon, 3 Jun 2019 at 22:19, Colvin Cowie
wrote:
> Hi, thanks I'll give that a go when I get a chance.
>
> I was trying to reply to an older
Hi, thanks I'll give that a go when I get a chance.
I was trying to reply to an older thread (
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201904.mbox/%3CCAF2DzVXeVZqnixnkbzw0La1ui5N5-RG9PwfMBHG9vmkfBSMzJA%40mail.gmail.com%3E),
which I don't have in my mailbox, so obviously didn't re
Hi Colvin,
We're still taking a look at fixing the bug, but as a workaround in
the meantime, you can look into adding a "forwardCredentials":true
property under the "authentication" section of security.json. That
seems to fix the issue in my reproduction at least.
e.g.
{
"authentication": {
One last note: as far as I can tell, nothing about this issue is
specific to JSON Faceting or the JSON request API. It can be
triggered just as easily with "/select?q=*:*".
The bug created for this is: SOLR-13510
On Mon, Jun 3, 2019 at 9:17 AM Jason Gerlowski wrote:
>
> I'm also able to reprodu
I'm also able to reproduce this bug on master. A few more notes about
the bad behavior:
- the behavior occurs regardless of the specific permissions
configured in security.json. (i.e. whether the top permission is
"all", or "security-edit", or there are no permissions at all.)
- I tried looking
Hello. I encountered this issue too and wrote this up before I found this
thread, but I thought I might as well post it still, if it helps...
Currently I'm trying to move our product on to Solr 8.1.1. We are currently
using 6.6.6, so things have definitely moved on.
We use the BasicAuthPlugin + R
Hi All,
I am trying to use fcs method of faceting and set the facet thread count to
3 .But when I check the thread dump around 15 threads are visible for
faceting.
Do setting facet thread count to 3 open 3 thread for each segment?
On what basis should we decide no facet threads?
Thanks
Hi All,
I am trying to use fcs method of faceting and set the facet thread count to
3 .But when I check the thread dump around 15 threads are visible for
faceting.
Do setting facet thread count to 3 open 3 thread for each segment?
On what basis should we decide no facet threads?
Thanks
Saurabh
1 - 100 of 2667 matches
Mail list logo
