Hi Isabelle
Thanks for your input.
In fact SolR returns 30 results out of this queries. Why does it behave in a
way that causes OOM ? Also the commands, they are SQL commands and solr would
parse it as normal character …
Thanks
> On 10 Jun 2020, at 22:50, Isabelle Giguere
> wrote:
>
> Hi Gu
Hi Mikhail
Your suggested solution does seem to work for me. Thank you so much for the
help!
Best regards
David
For future reference in case someone else wants do the same, here are some more
details about the steps needed:
- The more like this handler is not in the default solrconfig.xml anym
Hi,
Can someone shed some light on this issue please?
Regards,
Vinodh Kumar K
Middleware Cache and Search Engineering
DTCC Chennai
[cid:image006.png@01D2A70B.AF8789E0]
From: Kommu, Vinodh K.
Sent: Wednesday, June 10, 2020 10:43 PM
To: solr-user@lucene.apache.org
Subject: RE: Timeout issue whi
equest(RequestHandlerBase.java:211)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2596)
with queries like
> q=*:*
>
> &fl=docId,id,typeId,versjonsId,start_date,out_link_*,regulars,spatials,associations
> &fq=(typeId:945 AND exportId:hex0945)
> &fq=docType
Although you can use nested maps, for injecting variable values, I would
have used an intermediate script that makes the Solr URL.
On Wed, 10 Jun 2020 at 08:58, Derek Poh wrote:
> I have the following boost requirement using bf
>
> response_rate is 3, boost by ^0.6
> response_rate is 2, boost by
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 a
Guilherme,
The answer is likely to be dependent on the query parser, query parser
configuration, and analysis chains. If you post those it could aid in
helping troubleshoot. One thing that jumps to mind is the asterisks
("*") -- if they're interpreted as wildcards, that could be
problematic? More g
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> use the deprec
I have a Solr atomic json update job running successfully for adding values
on specific fields, but two fields description/keywords (i am using Nutch
web crawler) contents are dropped after json atomic update. Could not
figure out why
Any helps are appreciated.
--
Sent from: https://lucene.472
Could you explain why the performance is an issue for points-based fields? I've
looked through the referenced issue (which is fixed in the version we are
running) but I'm missing the link between the two. Is there an issue to improve
this for points-based fields?
We're going to change the field
Some extra info:
Collections have 1 shard, 1 replica. Only 1 Solr node running.
The HTTP 401 is not intermittent, as reported in SOLR-13421 and SOLR-13510.
Any request to the alias fails.
Thanks;
Isabelle Giguère
Computational Linguist & Java Developer
Linguiste informaticienne & développeur j
Are they stored=true?
On Thu, Jun 11, 2020, 10:14 Dongtao wrote:
> I have a Solr atomic json update job running successfully for adding values
> on specific fields, but two fields description/keywords (i am using Nutch
> web crawler) contents are dropped after json atomic update. Could not
> fi
On Wed, Jun 10, 2020 at 8:35 PM Hup Chen wrote:
> I will check "dmesg" first, to find out any hardware error message.
>
Here is what I see toward the end of the output from dmesg:
[1521232.781785] [118857]48 118857 108785 677 201
901 0 httpd
[1521232.781787] [118860]
1. You have a tiny heap. 536 Megabytes is not enough.
2. I stopped using the CMS GC years ago.
Here is the GC config we use on every one of our 150+ Solr hosts. We’re still
on Java 8, but will be upgrading soon.
SOLR_HEAP=8g
# Use G1 GC -- wunder 2017-01-23
# Settings from https://wiki.apache.o
Hello all,
We are using Solr 7.7.3 (SolrCloud, 2 nodes w/zookeepers per data center) and
today we started to receive alerts:
CdcrReplicator Failed to forward update request to target: Authors
java.lang.ClassCastException: class java.lang.Long cannot be cast to class
java.util.List (java.lang.Lo
This works: &f.interests.facet.matches=hockey|soccer
--
Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
We are running a test case, ingesting 2B records in a collection in 24 hrs.
This collection is spread across 10 solr nodes with a replication factor of
2.
We are noticing many replicas going into recovery while indexing. And it is
degrading indexing performance.
We are observing errors like:
*org
17 matches
Mail list logo
