R: SolrCloud availability when a server is down
Thanks a lot to everyone My component is in Net7 e I don't use any solrclient, so I think i will implement a simple round-robin schedule in my software for a simple failover. Your answers cleaned my doubts Umberto Facchin Servizi e sistemi per ambiente, territorio e agricoltura Divisione Pubblica Amministrazione Digitale Insiel S.p.A. via Cotonificio, 127 33100 -Udine (UD) Italia tel +39 0432 557228 mob +39 335 1824475 umberto.facc...@insiel.it www.insiel.it rispetta l'ambiente: se non ti è necessario non stampare questa mail -Messaggio originale- Da: uyil...@vivaldi.net.INVALID Inviato: martedì 9 gennaio 2024 08:40 A: users@solr.apache.org Oggetto: Re: SolrCloud availability when a server is down If your backend is in Java, SolrJ can do the same too. You instantiate a SolrJ instance using the zookeeper URL instead of a specific Solr node url, and it keeps itself in sync with live nodes list and forwards requests to whichever node is alive From: Rigolin, Dario Sent: Tuesday, January 9, 2024 10:33 AM To: users@solr.apache.org Subject: Re: SolrCloud availability when a server is down Some Solr Client (I use Solarium for PHP) has the ability to handle load balancing and failover, you have to put in the connect string all nodes address and the client library will connect to another node in case of failure. Il giorno lun 8 gen 2024 alle ore 18:34 Facchin Umberto < umberto.facc...@insiel.it> ha scritto: > Hi, > > > > I'm doing some tests to use SolrCloud (8.11.2) with 3 servers, each > with 1 Zookeeper and 1 Solr > > > > I have a search component that executes queries via GUI using the url to > server1_ip, i.e. with the address > http://server1_ip:8983/solr/collection/query?q=*:* > > > > If server2 or server3 are down everything continues to work (even the > updates), but if server1 is down then everything stops, obviously. > > > > Is there a way to configure a URL that always responds regardless of > the server's IPs? > > Or should I wait for zookeeper to restart solr on server1? > > Or what is wrong on my approach? > > > > Thanks > > > Umberto > Divisione Pubblica Amministrazione Digitale Servizi e sistemi per > ambiente, territorio e agricoltura Cartografia > > Insiel S.p.A. > > AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute > nel messaggio o nei suoi allegati. Se non siete i destinatari indicati > nel messaggio, o responsabili per la sua consegna alla persona, o se > avete ricevuto il messaggio per errore, siete pregati di non > trascriverlo, copiarlo o inviarlo ad alcuno. In tal caso vi invitiamo > a cancellare il messaggio ed i suoi allegati. Grazie. > CONFIDENTIALITY NOTICE Confidential information may be contained in > this message or in its attachments. If you are not the addressee > indicated in this message, or responsible for message delivering to > that person, or if you have received this message in error, you may > not transcribe, copy or deliver this message to anyone. In that case, > you should delete this message and its attachments. Thank you. > -- Dario Rigolin Comperio srl - CTO Mobile: +39 347 7232652 - Office: +39 0425 471482 Skype: dario.rigolin AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo ad alcuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.
Re: SolrCloud availability when a server is down
On 1/8/24 10:32, Facchin Umberto wrote: If server2 or server3 are down everything continues to work (even the updates), but if server1 is down then everything stops, obviously. Solr has no features to get around this. What you need is something that manages a virtual IP address among multiple servers. Optionally you could have that virtual IP address live on a set of machines that operate a load balancer sitting in front of your SolrCloud cluster. Things I have seen that can do this include: pacemaker keepalived ucarp Thanks, Shawn
SolrJ with Spring Boot 3.2
Hello Everyone at Solr This Email is possibly a duplicate, but as I did not find my Mail appear in the archives the first time I'm sending it a second time. Today I wanted to bump the Spring Boot version from 3.1.7 to 3.2.1. With the first Version my application just worked, but now I get the fallowing Exception: Failed to instantiate [org.apache.solr.client.solrj.SolrClient]: Factory method 'solrClient' threw exception with message: org/eclipse/jetty/client/util/InputStreamResponseListener The Problem is, that InputStreamResponseListener was moved to a new package. org.eclipse.jetty.client.util to org.eclipse.jetty.client (without util). This was changed in https://github.com/jetty/jetty.project/commit/a1c5cefd0d5657df04e5364cca9315aa4e2a1aef The newest SolrJ Version 9.4 still uses an older eclipse client 10.0.17 (BEFORE the namespace change). https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-parent/3.1.7#:~:text=jetty%2Dreactive%2Dhttpclient-,3.0.11,-4.0.2 While Spring Boot Starter Parent 3.1.7 uses jetty-reactive-httpclient 3.0.11 https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-reactive-httpclient/3.0.11#:~:text=%C2%BB%20jetty%2Dclient-,11.0.19,-12.0.5 And jetty-reactive-httpclient 3.0.11 uses jetty-client 11.0.19 (which is compatible with 10.0.17) The Spring Boot Starter Parent uses 12.0.17 (AFTER the namespace change), which in turn results in a conflict. You can find the version being used indirectly https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-parent/3.2.1#:~:text=jetty%2Dreactive%2Dhttpclient-,4.0.1,-4.0.2 The spring boot starter uses jetty-reactive-httpclient 4.0.1 https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-reactive-httpclient/4.0.1#:~:text=%C2%BB%20jetty%2Dclient-,12.0.3,-12.0.5 jetty-reactive-httpclient 4.0.1 uses jetty-client 12.0.3 TLDR: If you upgrade from spring boot starter parent 3.1.7 to 3.2.1 a new jetty client will be used, which conflicts with the jetty client being used by solrj Can I create a Ticket on your Jira (I already have a Jira account) or is there already a ticket about this issue? With kind regards, Coop Genossenschaft Dario Viva 4002 Basel
Re: SolrJ with Spring Boot 3.2
On 1/9/24 10:14, dario.v...@coop.ch wrote:
Hello Everyone at Solr
This Email is possibly a duplicate, but as I did not find my Mail appear in the
archives the first time I'm sending it a second time.
Today I wanted to bump the Spring Boot version from 3.1.7 to 3.2.1.
With the first Version my application just worked, but now I get the fallowing
Exception:
Failed to instantiate [org.apache.solr.client.solrj.SolrClient]: Factory method
'solrClient' threw exception with message:
org/eclipse/jetty/client/util/InputStreamResponseListener
The Problem is, that InputStreamResponseListener was moved to a new package.
org.eclipse.jetty.client.util to org.eclipse.jetty.client (without util).
SolrJ uses the Jetty Client version 10.
Spring Boot 3.2.1 updates all Jetty dependencies to version 12.0.5, and
neither Solr nor SolrJ has been qualified to work with Jetty 12.
I do not know what dependency manager you are using, but I found the way
to force Jetty dependencies to version 10 in gradle using a
"configurations" section:
plugins {
id 'java'
id 'org.springframework.boot' version '3.2.1'
id 'io.spring.dependency-management' version '1.1.4'
}
group = 'org.elyograg.test'
version = '0.0.1-SNAPSHOT'
java {
sourceCompatibility = '17'
}
repositories {
mavenCentral()
}
configurations {
all {
resolutionStrategy {
eachDependency { DependencyResolveDetails details ->
if (details.requested.group ==
'org.eclipse.jetty') {
details.useVersion '10+'
}
}
}
}
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter'
implementation group: 'org.apache.solr', name: 'solr-solrj', version:
'9+'
testImplementation 'org.springframework.boot:spring-boot-starter-test'
}
tasks.named('test') {
useJUnitPlatform()
}
Thanks,
Shawn
Re: Optimize latency of queries with facets
Hi David, I'm following this topic. Would you please elaborate a little bit why docValues on a boolean field might be a bad idea? Is this specific to a Solr major release, or more a general concern? Do you have a documentation link to share? We were told that docValues should be enabled on facetted fields to improve performance, so are boolean types an exception here? Thank you, Mirko Am 08.01.2024 um 01:27 schrieb David Smiley: Enabling docValues on a boolean field is probably not a good idea. If disabling that doesn't help (and I do think it will), then you might want to use a simple string field that a doc either has the name of the boolean (if true) or does not, then facet on that. On Thu, Jan 4, 2024 at 3:18 PM Mikhail Khludnev wrote: How does it work with facet.method=enum? Slicing to even smaller shards makes sense. On Wed, Jan 3, 2024 at 12:10 AM rajani m wrote: Hi Solr Users, Queries with facets show 2x increase in latency. This facet field is a boolean field with docvalues enabled[1]. Same queries without facets have ~50 ms and with facets it is ~120ms. Is this an expected performance? Appreciate any suggestions to optimize it. Additional details - I am querying a single shard, distrib=false&cache=false, standard query such as "&q=cats&defType=edismax&qf=keywords title desc body" have ~50 ms qtime and with facets (facet=true&facet.field=has_color) it is jumping to 120ms. Is this expected performance with facets, or are there other factors that could be cause result to such increase in the latency? Could this be because of shard index size which is 65 gb, is this big? and would splitting the shard into a 30gb size improve the performance? Cpu and ram should not be a concern, the node hosting shard has enough ram to fit the entire shard index and has 16vcpus. What other factors can result in increasing latency? Appreciate suggestions to improve the latency. [1] sortMissingLast="true" omitNorms="true" docValues="true"/> Thanks, Rajani -- Sincerely yours Mikhail Khludnev
