Hi Damien,
You mention about JSON term facets, I haven't explored w.r.t. that but we have
observed what you describe for JSON range facets and I've started
https://issues.apache.org/jira/browse/SOLR-14939 about it.
Hope that helps.
Regards,
Christine
From: solr-user@lucene.apache.org At:
Hi,
If you use a high value for the score, the values on the smaller scale are
ignored.
Example :
bq = foo:(1.0)^1.0
bf = sum(200)
When I do this, the additional score for "foo" at 1.0 does not affect the
sort order.
I'm assuming this is an issue with the precision of the score floating
You’d get a much better idea of what goes on
if you added =true and analyzed the
output. That’d show you exactly what is
calculated when.
Best,
Erick
> On Oct 22, 2020, at 4:05 AM, Taisuke Miyazaki
> wrote:
>
> Hi,
>
> If you use a high value for the score, the values on the smaller scale
Kris,
>From a user's standpoint, the DIH is not deprecated. I think we as a
project screwed up the messaging around components in Solr that are
*moving* in terms of code maintenance. That is not deprecation yet we
referred to it as such, hence your understandable confusion. I corrected
the
Im dong a nested facet (
https://lucene.apache.org/solr/guide/8_6/json-facet-api.html#nested-facets)
or sub-facets, and am using the 'terms' facet.
Digging around more looks like I can set 'cacheDf=-1' to disable the use of
the cache.
On Fri, 23 Oct 2020 at 00:14, Michael Gibney
wrote:
>
Hi All
I've been trying to get a metric trigger set up in SolrCloud 8.4.1, but
it's not working, and was hoping for some help.
I've created a metric trigger using this:
```
POST /solr/admin/autoscaling {
"set-trigger": {
"name": "metric_trigger",
"event": "metric",
"waitFor":
Hi,
We've got a 3 node SolrCloud cluster running on GKE, each on their own kube
node (which is in itself, relatively empty of other things).
Our collection has ~18m documents of 36gb in size, split into 6 shards with
2 replicas each, and they are evenly distributed across the 3 nodes. Our
JVMs
Damien,
Are you able to share the actual json.facet request that you're using
(at least just the json.facet part)? I'm having a hard time being
confident that I'm correctly interpreting when you say "a json.facet
query on nested facets terms".
Michael
On Thu, Oct 22, 2020 at 3:52 AM Christine
I'm sure that this is not the case. On the Java Properties page it says
"solr.allowPaths *", on the dashboard I can verify that the
"-Dsolr.allowPaths=*" option is present.
Am Mi., 21. Okt. 2020 um 19:10 Uhr schrieb Jan Høydahl <
jan@cominvent.com>:
> Are you sure the * is not eaten by the
Hey we face similar kind of issue . Our version of Solr is 8.5.1.Also we run
as docker containers in ubuntu server.
Could you provide similar solution ?
--
Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Well, we are not making the http requests to solr, we are using a 3rd party
component for that, which as configuration basically only takes a base URL (ie
domain, port etc, without path) and the name of the collection. So it is not
possible to define the request parser here. So we would have to
Why not have a custom handler endpoint for your online queries? You
will be modifying them anyway to remove fq.
Or even create individual endpoints for every significant use-case.
You can share the configuration between them with initParams or
useParams, but have more flexibility going forward.
Hi,
We have multiple components that uses the Solr search feature on our websites.
But we have some documents in the index that we never want to display in the
search results (nothing secret or anything, just uninteresting for the user to
see). So far, we have added a fq to all our queries,
Hi Shawn,
I.m circling back with some new findings with our 2 NUMA issue. After a
few iterations, we do see improvement with the useNUMA flag and other JVM
setting changes. Here are the current settings, with Java 11:
-XX:+UseNUMA
-XX:+UseG1GC
-XX:+AlwaysPreTouch
-XX:+UseTLAB
Great updates. Thanks for keeping us all in the loop!
On Thu, Oct 22, 2020 at 7:43 PM Wei wrote:
>
> Hi Shawn,
>
> I.m circling back with some new findings with our 2 NUMA issue. After a
> few iterations, we do see improvement with the useNUMA flag and other JVM
> setting changes. Here are the
15 matches
Mail list logo
