Thanks Eric, Charlie and Yuval for all the feedback and suggestions.
Eric: Yes I thought the monitoring might be a it of a pain, esp with
millions of them, I'll have to check out the topic code, but I wondered if
I can look @ the checkpoint collections for uniqueIds that haven't been
updated for a
Hi All,
We are getting OOM errors in the solr logs for only specific solr stores.
And in the solr logs we see the below error. Is the OOM error could be
because of the below error.
Also i see below Lazyfield error is spanned across thousands of lines.
Please advise. This is a PROD environment.
Hi Dan,
Yuval and my suggestions both rely on the same underlying code (Luwak,
now called Lucene Monitor). This lets you store a set of Lucene queries
and run them against every new document.
The Lucene Monitor allows for very high-performance matching (I know of
situations with around 1m st
I doubt these are related, that second error looks like something
triggered by indexing - attempting to add multiple values to a field
that hasn't been defined in the schema as multivalued. I'd review your
indexing process and schema first.
Charlie
On 07/09/2021 11:00, HariBabu kuruva wrote:
Thank you Charlie.
Please let me know if anything is required from my end.
Also, we have added below filed as a work around
false in solrconfig.xml
On Tue, Sep 7, 2021 at 4:03 PM Charlie Hull
wrote:
> I doubt these are related, that second error looks like something
> triggered by indexing - a
Sorry I should have worded that better - I suggest that you review your
schema file and indexing process, so that you can understand why
multiple values are being sent to the field 'quoteSLOCurrentStatus' when
it's probably not defined as multivalued.
C
On 07/09/2021 12:30, HariBabu kuruva wr
There was a design implemented in Streaming Expression for large scale
alerting described here:
https://joelsolr.blogspot.com/2017/01/deploying-solrs-new-parallel-executor.html
In this design you would store each alert in Solr as a topic expression.
Then a single daemon can run all the topics or
Hi Charlie,
The multiple values error is not occurring only for that field. Its also
occurring for multiple fields and multiple stores(collections).
Ex:
2021-09-07 13:05:53.646 ERROR (qtp1198197478-1200) [c:quoteStore s:shard1
r:core_node8 x:quoteStore_shard1_replica_n7] o.a.s.h.RequestH
andlerBas
Also, I think this is something you could easily trial, just take out the Kafka
step, and replace it with say a insert into a solr collection, and see what
happens.
Monitoring the daemon process is easy too ;-)
> On Sep 7, 2021, at 8:50 AM, Joel Bernstein wrote:
>
> There was a design imple
The general answer is to add UpdateRequestProcessor pipeline. That gives
you a lot of post processing flexibility.
But you can also try having the xpath specify /text(), maybe that will
deal with space specifically. Did not test it myself though, just a
thought.
Regards,
Alex
On Mon.,
We're using Solr 6.6.6, with SolrJ 7.7.1.
We've started on supporting use of Basic Authentication with Solr, so we need
to include credentials when connecting and sending requests. It's clear that
we can include the credentials in each SolrRequest. However, we are not always
building individu
I don't know, but perhaps 8.8.1 checks it more than 8.1? - it's still
worth your dev team reviewing as I suggested as it may be linked to why
the nodes are going down. The error is occurring for a reason.
Charlie
On 07/09/2021 14:30, HariBabu kuruva wrote:
Hi Charlie,
The multiple values err
> How long are you waiting between the hard commit and the query?
> Are you waiting for the commit operation to return a response before you
try to
> query?
Well that's kind of the crux of the issue. We're issuing a hard commit
which (from what I've read) appears to be a synchronous operation. So.
> Is there a particular reason for using TLOG replica types?
We used to use NRT replica types, but we switched to TLOG a year or two ago
in order to prioritize indexing speed above all else, understanding that it
might take a while for query results to be identical across replicas. This
is the fi
> On Sep 7, 2021, at 9:01 AM, lstusr 5u93n4 wrote:
>
> Well that's kind of the crux of the issue. We're issuing a hard commit
> which (from what I've read) appears to be a synchronous operation. So. when
> the call comes back with a 200 http response code, we can be assured that
> the operation h
How about doing your queries against the leader only?
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Sep 7, 2021, at 9:06 AM, lstusr 5u93n4 wrote:
>
>> Is there a particular reason for using TLOG replica types?
>
> We used to use NRT replica types
> How about doing your queries against the leader only?
This seems to work. We haven't been able to produce an instance where the
primary data isn't there in the case where we bound the queries only to the
leaders.
> Solr is not transactional. You are assuming ACID properties,
> but Solr does no
Alexandre,
perfect!!!
There is a built in white space trim factory,
TrimFieldUpdateProcessorFactory that I added to the default chain and now all
is good!
thanks again,
Scott
On 9/7/21 7:32 AM, Alexandre Rafalovitch wrote:
The general answer is to add UpdateRequestP
* Are there any constraints as to how to safely call the /update handler for a
core from multiple clients?
* Are there locking issues we should be aware of?
* Is there any way multiple /update calls can corrupt a core?
Backstory:
Back in 2013, when we first started using Solr 4.2.0, we had pro
On 9/7/2021 4:00 AM, HariBabu kuruva wrote:
We are getting OOM errors in the solr logs for only specific solr stores.
And in the solr logs we see the below error. Is the OOM error could be
because of the below error.
There are precisely two ways to deal with OOME. One is to increase the
siz
On 9/7/2021 10:01 AM, lstusr 5u93n4 wrote:
Seems like our experimentation is showing that it doesn't at least for TLOG
replica types. If we bound the query to the leaders, we can get accurate
results immediately after the commit. If we don't add that restriction,
sometimes the results sometimes w
On 9/7/2021 3:08 PM, Shawn Heisey wrote:
I don't think there's a reliable way of asking Solr to tell you when
all replications are complete.
You could use the replication handler (/solr/corename/replication) to
gather this info and compare info from the leader index with info from
the follo
Hi All,
Recently one of our solr nodes thrown an error:
...
2021-09-07 00:15:03.258 ERROR (qtp1278677872-985164)
[c:userRequestResults_----0001 s:shard1
r:core_node7
x:userRequestResults_----0001_shard1_replica_n4]
o.a.s.c.SolrCore java.lang
23 matches
Mail list logo
