Hi,
we have a production environment that runs solr in cloud mode and we have
a testing environment that runs solr in standalone mode. From time to time
we use a database dump of our production environment and import it to the
testing environment. Since it would take too long to build the solr ind
iple solr instances the backup and restore
> > > must be in a NFS filesystem, shared by all the instances servers.
> > > > Test it and tell us! Luck with it!
> > > >
> > > > Kind regards.
> > > >
> > > >
> > > > D
Sounds good :-)
Thanks!
On Mon, Jul 25, 2022 at 4:13 PM Jason Gerlowski
wrote:
> Good question: I guess my plan would be to keep it around for the
> remainder of the 9.x line, and then remove it for 10.0.
>
> Best,
>
> Jason
>
> On Tue, Jul 19, 2022 at 2:33 AM michael
Hi,
today we updated solr to version 9.1 (lucene version 9.3)
Since then we noticed plenty of TooManyNestedClauses in the logs. Our
setting for maxClauseCount is 1024
I played around a lot and could trace it down to this:
* I built an index from scratch with two fields (id is unique key) and
luce
at 2:09 PM Jan Høydahl
> wrote:
> >
> > > Have you tried using Terms Query? It is much more efficient than many
> > > boolean should clauses
> > >
> > > ?q={!terms f=id}1 2 3 4...1025
> > >
> > > Jan
> > >
> > > >
l get errors above.
>
> Jan
>
> > 2. des. 2022 kl. 07:43 skrev michael dürr :
> >
> > Thanks to all of you for your advice on using the terms query! I wasn't
> > aware of this syntax until now.
> >
> > Anyways it would be good to know whether
Hi Hoss,
I'm happy to provide some details as I still do not really understand the
difference to the situation before.
In case something like categoryId:[1 TO 1] also gets converted to some
boolean term, then it's clear to me.
Otherwise I do not understand why half the boolean clauses (512 + 1)
al
Hi Hoss,
This is a really helpful explanation!
Even though I already shifted to the usage of the {!terms} query for such
large boolean clause queries, it feels a lot better to know how and why
things behave differently compared to the 8x solr version.
Thanks!
Michael
On Tue, Dec 6, 2022 at 7:32
Hi,
Since we have updated to Solr 9.1, the admin ui has become pretty slow.
The problem is related to the fact that we run solr and the zookeeper
ensemble dockerized. As we cannot bind zookeeper from docker to its host's
external ip address, we have to use "0.0.0.0" as the server address which
ca
i.sh -z $ZK_HOST -cmd ls /live_nodes
> time server/scripts/cloud-scripts/zkcli.sh -z $ZK_HOST -cmd get
> /configs/_default/stopwords.txt
>
> What kind of timings do you see?
>
> Jan
>
> > 14. des. 2022 kl. 13:23 skrev michael dürr :
> >
> > Hi,
> >
>
these zk's dockerized, but I'd look for a
> workaround where you can configure the correct address in zk's
> configuration. Then Solr will be happy.
>
> Are you saying that in 8.11, the test with zkcli.sh to 0.0.0.0:2181
> returns immediately instead of after 30s?
>
Hi,
I recently observed that calls to the metrics api get stuck (thread state
waiting) when we call it for an index that is built from scratch. This
became a problem when we used the solr metrics exporter and unexpectedly
ran out of memory due to the accumulating threads.
This is one of the waiti
ThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:289)",
"org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$256/0x000800e4fd48.run(Unknown
Source)",
"java.base@17.0.6
/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java
awn Heisey wrote:
> On 7/11/23 21:50, michael dürr wrote:
> > The solr version I'm running is 9.2.1 and it is not customized (not
> > compiled from source).
> >
> > I scanned the whole stack trace for that object reference, but could only
> > find threads that s
14 matches
Mail list logo
