Could this be related to thread issues in Solr?
On Fri, Feb 17, 2023 at 4:44 PM Mark Hieber wrote:
> I agree. However, what we are seeing is that a query *will return the
> document* when we check for eventual consistency, but when we check some
> time later (say 5 minutes), then we do not get t
I agree. However, what we are seeing is that a query *will return the
document* when we check for eventual consistency, but when we check some
time later (say 5 minutes), then we do not get the document returned. So it
got the document correctly, and returned the results, but then later it did
not
Query the database to see whether the document is in the database.
The problem happens when you don’t follow the design pattern “single source of
truth”. Solr has a delayed version of the true state, so it will sometimes give
wrong answers.
https://en.wikipedia.org/wiki/Single_source_of_truth
Well.. I missed the fact that implementation went so far already.
This particular case
https://solr.apache.org/guide/8_11/updating-parts-of-documents.html#updating-child-documents
should work, I believe.
On Fri, Feb 17, 2023 at 11:27 PM dmitri maziuk
wrote:
> On 2023-02-17 2:14 PM, Mikhail Khlu
OK, I am officially an idiot. Apologies for the noise everyone.
(The answer is there was one uncommitted change in the importer script
hiding on the development host -- something `git pull origin` doesn't
tell you about. Bad git.)
Cheers,
Dima
On 2023-02-17 2:14 PM, Mikhail Khludnev wrote:
Pardon. I'm lost.
Are you using
https://solr.apache.org/guide/solr/latest/indexing-guide/indexing-nested-documents.html
?
With that approach it's not possible to put parents and children
separately, they go strictly altogether.
So this:
https://so
Pardon. I'm lost.
Are you using
https://solr.apache.org/guide/solr/latest/indexing-guide/indexing-nested-documents.html
?
With that approach it's not possible to put parents and children
separately, they go strictly altogether.
On Fri, Feb 17, 2023 at 8:22 PM dmitri maziuk
wrote:
> On 2023-02-16
We have a cluster of hosts running Solr 8.4 Each host has an application
which listens to an external source for updated documents. When it gets a
document we care about, it indexes that document into the correct Solr core
(we are not running cloud).
In our API service, when we get a request to pu
I have created the ticket: https://issues.apache.org/jira/browse/SOLR-16670
On Fri, 17 Feb 2023 at 22:08, Hakan Özler wrote:
> I have tried this with 9.1.0 as well, but received the same error.
> I also have a similar doubt about what you have addressed.
>
> Could you create a JIRA issue for thi
I have tried this with 9.1.0 as well, but received the same error.
I also have a similar doubt about what you have addressed.
Could you create a JIRA issue for this?
Sure, I'll do it.
Thanks!
Hakan
On Fri, 17 Feb 2023 at 20:54, Houston Putman wrote:
> Did this work in a previous version (9.1.
Did this work in a previous version (9.1.0, 9.0) for you, or have you just
started trying it with 9.1.1?
We had a change to some ZK/Backup integration in 9.1.1, but I don't think
that's the issue here.
Instead it looks like the AWS APIs return an error when they previously did
not.
Overall it loo
>
> I couldn't get Http2SolrClient to work at all without giving it an
> SSLConfig object. Jetty HttpClient throws NPE saying it does not have
> SslContextFactory. With HttpSolrClient I don't have to do anything with
> SSL config, it just works.
>
I think I found this issue here:
https://issues.
On 2023-02-16 11:59 PM, Mikhail Khludnev wrote:
Hello,
May all of them clash by uniqueKey? If it has place children may wipe
parent. What do you get on *:*?
uniqueKey does not clash between parent and child documents. Importer
POSTs all parents first, with "type" : "parent" and "id" : uuid5 de
Just to give some feedback on this thread:
After upgrading from Ubuntu 18.04 to Ubuntu 20.04 our 80 node Solr
8.11.2 / Java 11 cluster became less stable, with shards regularly
switching into down or recovering state, and with manual intervention
sometimes needed (restart of Solr instances to reco
14 matches
Mail list logo