solr search is not working when we use `WhitespaceTokenizerFactory` and wanted to search chinese character

[Vishal Patel]

I do have solr schema configuration for field "test" having "text" type and for 
it we have used solr.WhitespaceTokenizerFactory
Now data get indexed in solr for this "test" field but when we try to search 
it, I am not able to get result using solr query like below

field:(（第二期）) /  field:(（第二期）*)

For example: input value : （第二期） being index but when we try to search it than 
not able to get result.
I have tried to use solr.ShingleFilterFactory using query analyser but won't 
help here.
Any suggestions to fix the same ?
Thanks in advance !

Regards,
Vishal Patel

Re: TimeZones

[Chris Hostetter]

: So the solution would be to use TZ as described in 
: 
https://solr.apache.org/guide/solr/9_5/indexing-guide/date-formatting-math.html#tz
 
: But somehow this does not work as advertised. It wrongly returns 
: starting points in the perspective of utc aka: 00:00:00Z instead of 
: 23:00:00Z) . In your example where you use America/Los_Angeles it shows 
: that it correctly uses 2013-11-01T07:00:00Z and so on. I strongly 
: suspect that this is called differently in the json api (considering "q" 
: becomes "query" in the json api)

TZ is a global request param that affects the entire request.  

It can't be specified "per-facet" like you seem to be trying to do with 
your JSON query. 

(try adding it as a key to the top level json map, with "query" and 
"limit")

: GET https:///solr//query
: Accept: application/json
: Content-Type: application/json
: 
: {
: "query": "*:*",
: "limit": 0,
: "facet": {
:"series": {
:   "hardend": false,
:   "field": "",
:   "gap": "+1MONTH",
:   "start": "2024-01-01T00:00:00Z/MONTH",
:   "end": "2024-05-01T00:00:00Z",
:   "type": "range",
:   "TZ": "Europe/Zurich"
:}
: }
: }



-Hoss
http://www.lucidworks.com/

Re: CREATE via GUI or API fails - BaseHttpSolrClient$RemoteSolrException: Error from server

[Jan Høydahl]

The images did not make it to the list. Can you share them elsewhere?

Does it work if you disable authentication plugin? I see a HTTP 403 error in 
the log which suggests there is an auth issue. Are you using 
forwardCredentials=true? 
Which solr version are you on?

Jan Høydahl

> 16. mai 2024 kl. 21:03 skrev Ulli Franz :
> 
> 
> Hello everyone
> 
> I use a 3-node solrCloud with 3 Zookeeper nodes (all on VMWare at one 
> physical machine) and got stuck while creating new collections. From time to 
> time it works via API or GUI, but mostly i receive a 
> BaseHttpSolrClient$RemoteSolrException: Error from server
> 
> Here is what I see:
> 
> 
> 
> These are my already created Collections:
> 
> 
> 
> In security.json is set "blockUnknown": False in authentication and at the 
> end of the file, which is already copied to zookeeper. 
> 
> This is how the zookeeper status looks like:
> 
> 
> When trying to create a new collection i use either the GUI or (Python code 
> which works fine e.g. to get something like the Clusterstatus):
> createCollection = 
> "http://s03:8983/solr/admin/collections?action=CREATE=GPL_COLLECTION_10=2=1;
> status = requests.post(createCollection, auth=HTTPBasicAuth(user, password))
> 
> 
>  and receive status 500:
> 
> {'responseHeader': {'status': 500, 'QTime': 180017},
>  'error': {'metadata': ['error-class',
>'org.apache.solr.common.SolrException',
>'root-error-class',
>'org.apache.solr.common.SolrException'],
>   'msg': 'create the collection time out:180s',
>   'trace': 'org.apache.solr.common.SolrException: create the collection time 
> out:180s\n\tat 
> org.apache.solr.handler.admin.CollectionsHandler.submitCollectionApiCommand(CollectionsHandler.java:415)\n\tat
>  
> org.apache.solr.handler.admin.api.CreateCollectionAPI.createCollection(CreateCollectionAPI.java:133)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$0(CollectionsHandler.java:513)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:1265)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:315)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:293)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:226)\n\tat
>  
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:932)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:880)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:541)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:262)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:219)\n\tat
>  
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:246)\n\tat
>  
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:215)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:213)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)\n\tat
>  org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)\n\tat 
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1570)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:221)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1384)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:176)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:484)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1543)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:174)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1306)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:129)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)\n\tat
>  
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:228)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:141)\n\tat
>  
> 

Re: Solr 9.7.0 Release Date

[Jan Høydahl]

Hi

There is no date. We don’t plan releases in advance.

But a 9.6.1 release is soon to leave the station. You should check whether all 
your wanted fixes are in branch_9_6, if not feel free to back port the ones you 
care about.

Jan Høydahl

> 16. mai 2024 kl. 21:02 skrev Himanshu Soni :
> 
> Dear Solr Team,
> 
> I am reaching out to gather information regarding the release date of Solr
> version 9.7.0. Our team is particularly interested in the new security
> updates and fixes for vulnerabilities that this upcoming version is
> expected to include. Understanding the release timing will greatly assist
> us in planning our development and update cycles more effectively.
> 
> Could you please provide any available details on when Solr 9.7.0 is
> anticipated to be released? Additionally, if there are any preliminary
> release notes or documentation regarding the security enhancements, it
> would be immensely helpful for our preparations.
> 
> Thank you for your dedication to improving Solr and maintaining its robust
> security framework. We look forward to your response and to the continued
> enhancements in the new version.
> 
> Best regards,
> 
> Himanshu Soni

Re: Problems migrating solrj to run with SpringBoot 3

[Jan Høydahl]

You’ll have to wait for a later solr release with a compatible jetty. We have a 
plan to make jetty optional for SolrJ but it still is needed.

Jan Høydahl

> 16. mai 2024 kl. 19:07 skrev Luke Kot-Zaniewski (BLOOMBERG/ 919 3RD A) 
> :
> 
> Hard to say without seeing your project but jetty seems to be using slf4j as 
> of some time 
> https://github.com/jetty/jetty.project/blob/7d264e6024efc80124592124891fb6e25b1554af/jetty-core/jetty-http2/jetty-http2-hpack/src/main/java/org/eclipse/jetty/http2/hpack/HpackEncoder.java#L43
>  so I'd first check if you can just solve this by upgrading.
> 
> This might help give some context to what happened to jetty's logging impl 
> https://github.com/jetty/jetty.project/pull/4643
> 
> Keep in mind that spring boot can be opinionated about logging depending on 
> which starter you use 
> https://docs.spring.io/spring-boot/docs/2.0.x/reference/html/howto-logging.html#howto-logging
>  .. If the version of Jetty you are running against is linking through an 
> slf4j interface (as it has been for some time apparently) then you should be 
> able to use a different/more modern logging implementation (i.e. Logback) and 
> manage all of that just by adding the right dependency.
> 
> Luke
> 
> From: users@solr.apache.org At: 05/16/24 12:41:05 UTC-4:00To:  
> users@solr.apache.org
> Subject: Problems migrating solrj to run with SpringBoot 3
> 
> I'm in the process of upgrading a project that uses SolrJ to run with Spring
> Boot 3.  I've been able to keep the current version of my jars after migrating
> to SpringBoot 3.   SolrJ is working in some cases, but I've run into a problem
> where it is missing the logging class for Jetty.  I get this stack trace:
> 
> 
> java.lang.ExceptionInInitializerError: Exception
> java.lang.NoClassDefFoundError: org/eclipse/jetty/util/log/Log [in thread
> "http-nio-8080-exec-8"]
> 
>   at
> org.eclipse.jetty.http2.hpack.HpackEncoder.(HpackEncoder.java:48)
> 
>   at
> org.eclipse.jetty.http2.hpack.HpackFieldPreEncoder.getEncodedField(HpackFieldPre
> Encoder.java:45)
> 
>   at
> org.eclipse.jetty.http.PreEncodedHttpField.(PreEncodedHttpField.java
> :79)
> 
>   at
> org.eclipse.jetty.http.PreEncodedHttpField.(PreEncodedHttpField.java
> :85)
> 
>   at
> org.eclipse.jetty.http.PreEncodedHttpField.(PreEncodedHttpField.java
> :90)
> 
>   at org.eclipse.jetty.http.HttpFields.(HttpFields.java:48)
> 
>   at
> org.eclipse.jetty.client.transport.HttpRequest.(HttpRequest.java:68)
> 
>   at
> org.eclipse.jetty.client.HttpClient.newHttpRequest(HttpClient.java:449)
> 
>   at org.eclipse.jetty.client.HttpClient.newRequest(HttpClient.java:439)
> 
>   at
> org.springframework.http.client.JettyClientHttpRequestFactory.createRequest(Jett
> yClientHttpRequestFactory.java:135)
> 
> I've looked high and low to find this class.   I would hope that it would have
> been embedded in the SolrJ jar, but apparently not.  I'm using this version of
> Solrj:
> 
> 
>  
> 
>  org.apache.solr
> 
>  solr-solrj
> 
>  8.11.3
> 
>  
> 
> Along with
> 
>  
> 
> org.springframework.boot
> 
> spring-boot-starter-data-solr
> 
> 2.4.7
> 
>  
> 
> That is part of SpringBoot.
> 
> As far as I can tell, the only difference in the build is the version of
> SpringBoot libraries.
> 
> Any Ideas?
> 
> Thank you so much for your help.
> 
> Todd Stevenson
> 
> 
> NOTICE: This e-mail is for the sole use of the intended recipient and may
> contain confidential and privileged information. If you are not the intended
> recipient, you are prohibited from reviewing, using, disclosing or 
> distributing
> this e-mail or its contents. If you have received this e-mail in error, please
> contact the sender by reply e-mail and destroy all copies of this e-mail and
> its contents.
> 
> 

RE: Re: Number searches returning decimals

[Kemberli Holmes]

Hi Charlie,

I am wondering if your company can help us with our specific issue.  I looked 
over the training options offered.  Should I use the contact form from the 
website or can I take this conversation offline with you?  You can just email 
me directly please.  Thanks,

Kem

-Original Message-
From: Charlie Hull  
Sent: Thursday, May 16, 2024 2:54 AM
To: users@solr.apache.org
Subject: {External} Re: Number searches returning decimals

Hi Kem,

Each field in your schema will have an associated type. It might be useful to 
look at some of the examples supplied with Solr to understand in more depth how 
this works, or go through the tutorials 
https://urldefense.com/v3/__https://solr.apache.org/guide/solr/latest/getting-started/solr-tutorial.html__;!!M_q70DxGEbn10nk!XjuQz3rLIJgkE6zsLiVGw4EJRnHQJRgOiDhYjHqZrk2FqRO0dA5mK-FvCq4Fflsl2aWuj5qzvWGmIxX_kXm3yNYo$
 

There's also some training available for Solr - I wrote about this here:
https://urldefense.com/v3/__https://opensourceconnections.com/blog/2023/02/14/how-to-train-a-search-team-and-what-does-it-cost/__;!!M_q70DxGEbn10nk!XjuQz3rLIJgkE6zsLiVGw4EJRnHQJRgOiDhYjHqZrk2FqRO0dA5mK-FvCq4Fflsl2aWuj5qzvWGmIxX_kWf0EJpJ$
 

Cheers

Charlie

On 15/05/2024 23:24, Kemberli Holmes wrote:
> Hi Charlie,
>
> Thanks for your response. I am reading over the material you recommended.
> I am a novice to Solr.  There are several analysis chains defined in 
> my schema.xml.  They all have a fieldType name that starts with 
> "text".  How can I tell which one is being used?
>
> Thanks,
> Kem
>
> On Wed, May 15, 2024, 8:05 AM Charlie Hull 
> 
> wrote:
>
>> Whatever analysis chain you're using to turn your source data and/or 
>> queries into a normalised form is stripping out the decimal point.
>>
>> https://urldefense.com/v3/__https://solr.apache.org/guide/solr/latest
>> /indexing-guide/document-analysis.html__;!!M_q70DxGEbn10nk!XjuQz3rLIJ
>> gkE6zsLiVGw4EJRnHQJRgOiDhYjHqZrk2FqRO0dA5mK-FvCq4Fflsl2aWuj5qzvWGmIxX
>> _kXvwb4BF$
>> explains how this works and
>>
>> https://urldefense.com/v3/__https://solr.apache.org/guide/solr/latest
>> /indexing-guide/analysis-screen.html__;!!M_q70DxGEbn10nk!XjuQz3rLIJgk
>> E6zsLiVGw4EJRnHQJRgOiDhYjHqZrk2FqRO0dA5mK-FvCq4Fflsl2aWuj5qzvWGmIxX_k
>> Z4aBDaW$ will show what is actually happening in your index.
>>
>> Cheers
>>
>> Charlie
>>
>> On 14/05/2024 21:04, Kemberli Holmes wrote:
>>> Hello,
>>>
>>> We are running ColdFusion 2021 and were looking for some help with 
>>> Solr
>> and
>>> number searches.  When users search for a number such as 23019, 
>>> decimals such as 230.19 are returned.  Another example is a search 
>>> on 3373.  A
>> file
>>> with 33.73 was returned.  We would like to only get results that 
>>> have
>> that
>>> exact number in it—23019 or 3373.  Can you help us with the
>> configuration?
>>> A third example is a search on 901 is returning files with 90.1 in it.
>> But
>>> we just want hits that say 901.   We are using Solr 7.2.1.
>>>
>>>
>>> Thanks,
>>>
>>> Kem
>>>
>> --
>> Charlie Hull - Managing Consultant at OpenSource Connections Limited 
>> Founding member of The Search Network and co-author of Searching the 
>> Enterprise
>> tel/fax: +44 (0)8700 118334
>> mobile: +44 (0)7767 825828
>>
>> OpenSource Connections Europe GmbH | Pappelallee 78/79 | 10437 Berlin 
>> Amtsgericht Charlottenburg | HRB 230712 B
>> Geschäftsführer: John M. Woodell | David E. Pugh
>> Finanzamt: Berlin Finanzamt für Körperschaften II
>>
>>
--
Charlie Hull - Managing Consultant at OpenSource Connections Limited Founding 
member of The Search Network and co-author of Searching the Enterprise
tel/fax: +44 (0)8700 118334
mobile: +44 (0)7767 825828

OpenSource Connections Europe GmbH | Pappelallee 78/79 | 10437 Berlin 
Amtsgericht Charlottenburg | HRB 230712 B
Geschäftsführer: John M. Woodell | David E. Pugh
Finanzamt: Berlin Finanzamt für Körperschaften II


***CONFIDENTIALITY NOTICE***

This e-mail is intended for the sole use of the individual(s) to whom it is 
addressed, and may contain information that is privileged, confidential and 
exempt from disclosure under applicable law. You are hereby notified that any 
dissemination, duplication, or distribution of this transmission by someone 
other than the intended addressee or its designated agent is strictly 
prohibited. If you receive this e-mail in error, please notify me immediately 
by replying to this e-mail.

Vulnerability CVE-2023-44487 in solr-solrj 8.11.3

[Juan Luis Moreno Gomez]

Hello,

It seems that the latest version of solr-solrj 8 (8.11.3) library has the 
vulnerability CVE-2023-44487. It is detected by de Dependency-check tool an can 
be seen here: 
https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-18263/version_id-1776247/year-2023/opdos-1/Apache-Solr-8.11.3.html

Is there any plan to resolve this vulnerability soon in version 8 or the only 
solution is to update to Solr 9.4.0 or higher?

Thanks in advance.
CONFIDENCIALIDAD

La información contenida en este correo electrónico, y en su caso, cualquier 
fichero anexo al mismo, son de carácter privado y confidencial siendo para uso 
exclusivo de su destinatario. Si usted no es el destinatario correcto, el 
empleado o agente responsable de entregar el mensaje al destinatario, o ha 
recibido esta comunicación por error, le informamos que está totalmente 
prohibida cualquier divulgación, distribución o reproducción de esta 
comunicación según la legislación vigente y le rogamos que nos lo notifique 
inmediatamente, procediendo a su destrucción sin continuar su lectura.


PROTECCIÓN DE DATOS

Le informamos que su dirección de correo electrónico, así como el resto de los 
datos de carácter personal que nos facilite voluntariamente, podrían ser objeto 
de tratamiento automatizado por las empresas de SOFTTEK, con la finalidad de 
gestionar la agenda de contactos y contestar a sus solicitudes de información. 
La base que legitima el tratamiento es el interés legítimo de SOFTTEK y el 
consentimiento otorgado al ponerse en contacto. Podrá en cualquier momento 
ejercer sus derechos de acceso, rectificación, supresión, limitación del 
tratamiento, portabilidad y oposición en los términos establecidos en la 
normativa legal vigente mediante notificación escrita a la siguiente dirección: 
SOFTTEK. Att. Responsable Privacidad. Ctra. de la Coruña 38 (km.16,4) Las Rozas 
de Madrid, 28231-Madrid (España).


CONFIDENTIAL

The information contained in this email, and if applicable, any documents 
attached to it, are private and confidential and are for the exclusive use of 
the recipient. If you are not the correct recipient, the employee or agent 
responsible for delivering the message to its destination or have received the 
email by mistake, we inform you that it is strictly prohibited to disclose, 
distribute, or reproduce information from this email in accordance with 
existing legislation and we ask that you please notify us immediately, 
proceeding with its destruction without reading any further.


DATA PROTECTION

Your email address, as well as any other personal data you voluntarily provide 
to us, may be subject to automated processing by Softtek, in order to manage 
contacts and respond to your requests for information. The legal basis for 
processing is in the legitimate interest of Softtek with consent given when 
contacted. At any time, you may/can exercise your rights to access, modify, 
eliminate, limit the use of, transfer or oppose any contact according to the 
terms established by current legislation by written notification to the 
following address: Softtek Att. Responsable Privacidad. Ctra. de la Coruña 38 
(km.16,4) Las Rozas de Madrid, 28231-Madrid


Aviso de Privacidad | Privacy 
Notice | Aviso de 
Privacidade

Mean of "Current" field on core statistics page

[Yazhou, Aliaksei]

Hello dear colleagues,

In Solr web interface, when you choose a core, you can see a page with 
statistics.
In those statistics there is a field "Current" with possible values: "green 
checkmark" or "red crossed circle"
Question: what does the status mean actually?

Asking, as sometimes I see "red crossed circle" instead of green on my single 
node Solr instance.

Thank you in advance!

Best regards,



This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise confidential information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited. Where allowed by local law, electronic 
communications with Accenture and its affiliates, including e-mail and instant 
messaging (including content), may be scanned by our systems for the purposes 
of information security, AI-powered support capabilities, and assessment of 
internal compliance with Accenture policy. Your privacy is important to us. 
Accenture uses your personal data only in compliance with data protection laws. 
For further information on how Accenture processes your personal data, please 
see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
__

www.accenture.com

How to fix unstable solr cluster

[Sarthak Sharma]

Hi,

We have a production solr cluster setup with 4 shards and 4 replicas on a
legacy stack.
Same machines have been used to host 5 Zookeeper nodes ensemble.

Solr version : 1.1.0.41
ZK version : 3.4.6

Few days back, one of the solr processes was stuck because of which reads
and write were failing. We did a few rounds of ZK/Solr restarts after
clearing up disk space and read operations started working fine. but , the
write operations (indexing) started failing with below error :

Caused by:
org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
ClusterState says we are the leader (:/solr/),
but locally we don't think so. Request came from null

We checked the cluster state using below steps. (Solr UI is not accessible
for some reasons)


   1. Go to the path "zookeeper/installation/directory/bin"
   2. ./zkCli.sh -server localhost:1234
   3. get /clusterstate.json


We see that 3 shard replica nodes are STUCK in 'recovering' state.

The cluster is of critical importance and We want to use minimum possible
and safe changes to bring cluster back to stable state. Upgrading versions
is not possible either.


Please help us understand this behavior and way out of it.
Fixing this issue is really critical and urgent and we don't have enough
Solr expertise in the team.
This cluster was mainly in maintenance mode and in a deprecation path,
hence the situation.

Is there a way to force replication to unstable node from stable node?
Please let me know of your thoughts. Really appreciate any help.

Thanks,
Sarthak

CREATE via GUI or API fails - BaseHttpSolrClient$RemoteSolrException: Error from server

[Ulli Franz]

Hello everyone

I use a 3-node solrCloud with 3 Zookeeper nodes (all on VMWare at one physical 
machine) and got stuck while creating new collections. From time to time it 
works via API or GUI, but mostly i receive a 
BaseHttpSolrClient$RemoteSolrException: Error from server

Here is what I see:

[cid:bc5bb68a-15af-4c1f-aece-4929283ff29f]

These are my already created Collections:

[cid:5dd51a50-a540-4041-919d-a655530e9d2e]

In security.json is set "blockUnknown": False in authentication and at the end 
of the file, which is already copied to zookeeper.

This is how the zookeeper status looks like:
[cid:d7da20d2-1ba3-4c49-bcc4-9ac3158e55bb]

When trying to create a new collection i use either the GUI or (Python code 
which works fine e.g. to get something like the Clusterstatus):
createCollection = 
"http://s03:8983/solr/admin/collections?action=CREATE=GPL_COLLECTION_10=2=1;
status = requests.post(createCollection, auth=HTTPBasicAuth(user, password))


 and receive status 500:

{'responseHeader': {'status': 500, 'QTime': 180017},
 'error': {'metadata': ['error-class',
   'org.apache.solr.common.SolrException',
   'root-error-class',
   'org.apache.solr.common.SolrException'],
  'msg': 'create the collection time out:180s',
  'trace': 'org.apache.solr.common.SolrException: create the collection time 
out:180s\n\tat 
org.apache.solr.handler.admin.CollectionsHandler.submitCollectionApiCommand(CollectionsHandler.java:415)\n\tat
 
org.apache.solr.handler.admin.api.CreateCollectionAPI.createCollection(CreateCollectionAPI.java:133)\n\tat
 
org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$0(CollectionsHandler.java:513)\n\tat
 
org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:1265)\n\tat
 
org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:315)\n\tat
 
org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:293)\n\tat
 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:226)\n\tat
 org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:932)\n\tat 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:880)\n\tat
 org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:541)\n\tat 
org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:262)\n\tat
 
org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:219)\n\tat
 
org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:246)\n\tat
 
org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:215)\n\tat
 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:213)\n\tat
 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)\n\tat
 org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)\n\tat 
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)\n\tat
 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598)\n\tat
 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)\n\tat
 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1570)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:221)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1384)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:176)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:484)\n\tat 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1543)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:174)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1306)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:129)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)\n\tat
 
org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:228)\n\tat
 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:141)\n\tat
 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)\n\tat
 
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:301)\n\tat
 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)\n\tat
 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:822)\n\tat
 

Solr [3 nodes]/Zk [3nodes] GCP VM Setup with PD-SSD Disk || Indexing is taking 2 hours for 47 GB of data

[Sathish Ponnusamy]

Hi Team,



I am trying to setup solr(3 nodes) and zk(3 nodes) in GCP environment. All
the setup looks okay but except while indexing the data which is taking a
lot of time.



Below is the machine configuration and I already configured and loaded the
data into the local disk of one of the solr nodes before starting the
indexing  of the data into Solr cluster. The home directory of the solr is
in the pd-ssd persistent disk. And the index is also stored in the
Persistent disk.



*Solr nodes [3 nodes]:*

1.   c3d-highmem-16, local disk – 100GB [PD-SSD, Ephemeral], Persistent
disk [PD-SSD, 2000 GB]

2.   Solr version – 9.6.0, Java version -11, LuceneMatchVersion 9.9,

1.   9 shards,

2.   2 replication factor,

3.   JVM memory – 12G

4.   Autocommit/maxtime =  30

5.   Autosoftcommit/maxtime = 12

6.   Each document of the collection may be ~ 2kb size in json format



*ZK nodes [3 nodes]:*

1.   c3d-highcpu -4, local disk – 100GB [PD-SSD, Ephemeral], Persistent
disk [PD-SSD, 2000 GB]

2.   Zk version – 3.9.2, Java version -11


While ingesting the data into solr index noticed the CPU utilization &
memory is normal



Already tried below options from disk side:



1.  
https://cloud.google.com/compute/docs/disks/optimizing-pd-performance#no-ext3

2.  
https://cloud.google.com/compute/docs/disks/optimizing-pd-performance#formatting_parameters



Please let me know the way to increase the performance of solr indexing and
reduce the indexing hours.



Regards

Sathish P

Sathish Ponnusamy

Chennai
m: + 91 9962331981
e: sathishrp...@gmail.com

GitHub - github.com/sathishrpt24
 [image: Youtbue icon]

Re: How to fix unstable solr cluster

[Sarthak Sharma]

Hi Team,

Gentle reminder and request to help with this issue as we are kind of
stuck. Solr admin ui is also not opening up for us to do further debugging
and throws this error:

org.apache.zookeeper.KeeperException$ConnectionLossException:
KeeperErrorCode = ConnectionLoss for /overseer/collection-queue-work/qn- at
org.apache.zookeeper.KeeperException.create(KeeperException.java:99) at
org.apache.zookeeper.KeeperException.create(KeeperException.java:51) at
org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783) at
org.apache.solr.common.cloud.SolrZkClient$5.execute(SolrZkClient.java:243)
at
org.apache.solr.common.cloud.SolrZkClient$5.execute(SolrZkClient.java:240)
at
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73)
at org.apache.solr.common.cloud.SolrZkClient.create(SolrZkClient.java:240)
at
org.apache.solr.cloud.DistributedQueue.createData(DistributedQueue.java:311)
at org.apache.solr.cloud.DistributedQueue.offer(DistributedQueue.java:330)
at
org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:344)
at
org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:309)
at
org.apache.solr.handler.admin.CollectionsHandler.handleClusterStatus(CollectionsHandler.java:628

Our preference is to bring the cluster back to stable state with low
downtime and no data loss.
or At least admin ui starts opening up. Please suggest.

Thanks

On Sun, May 12, 2024 at 9:40 PM Sarthak Sharma  wrote:

> Hi,
>
> We have a production solr cluster setup with 4 shards and 4 replicas on a
> legacy stack.
> Same machines have been used to host 5 Zookeeper nodes ensemble.
>
> Solr version : 1.1.0.41
> ZK version : 3.4.6
>
> Few days back, one of the solr processes was stuck because of which reads
> and write were failing. We did a few rounds of ZK/Solr restarts after
> clearing up disk space and read operations started working fine. but , the
> write operations (indexing) started failing with below error :
>
> Caused by:
> org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> ClusterState says we are the leader (:/solr/),
> but locally we don't think so. Request came from null
>
> We checked the cluster state using below steps. (Solr UI is not accessible
> for some reasons)
>
>
>1. Go to the path "zookeeper/installation/directory/bin"
>2. ./zkCli.sh -server localhost:1234
>3. get /clusterstate.json
>
>
> We see that 3 shard replica nodes are STUCK in 'recovering' state.
>
> The cluster is of critical importance and We want to use minimum possible
> and safe changes to bring cluster back to stable state. Upgrading versions
> is not possible either.
>
>
> Please help us understand this behavior and way out of it.
> Fixing this issue is really critical and urgent and we don't have enough
> Solr expertise in the team.
> This cluster was mainly in maintenance mode and in a deprecation path,
> hence the situation.
>
> Is there a way to force replication to unstable node from stable node?
> Please let me know of your thoughts. Really appreciate any help.
>
> Thanks,
> Sarthak
>

Re: How to fix unstable solr cluster

[Sarthak Sharma]

A correction : SOLR version is 4.8.1 actually. Sorry for the miss.


On Tue, May 14, 2024 at 10:55 AM Sarthak Sharma 
wrote:

> Hi Team,
>
> Gentle reminder and request to help with this issue as we are kind of
> stuck. Solr admin ui is also not opening up for us to do further debugging
> and throws this error:
>
> org.apache.zookeeper.KeeperException$ConnectionLossException:
> KeeperErrorCode = ConnectionLoss for /overseer/collection-queue-work/qn- at
> org.apache.zookeeper.KeeperException.create(KeeperException.java:99) at
> org.apache.zookeeper.KeeperException.create(KeeperException.java:51) at
> org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783) at
> org.apache.solr.common.cloud.SolrZkClient$5.execute(SolrZkClient.java:243)
> at
> org.apache.solr.common.cloud.SolrZkClient$5.execute(SolrZkClient.java:240)
> at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73)
> at org.apache.solr.common.cloud.SolrZkClient.create(SolrZkClient.java:240)
> at
> org.apache.solr.cloud.DistributedQueue.createData(DistributedQueue.java:311)
> at org.apache.solr.cloud.DistributedQueue.offer(DistributedQueue.java:330)
> at
> org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:344)
> at
> org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:309)
> at
> org.apache.solr.handler.admin.CollectionsHandler.handleClusterStatus(CollectionsHandler.java:628
>
> Our preference is to bring the cluster back to stable state with low
> downtime and no data loss.
> or At least admin ui starts opening up. Please suggest.
>
> Thanks
>
> On Sun, May 12, 2024 at 9:40 PM Sarthak Sharma 
> wrote:
>
>> Hi,
>>
>> We have a production solr cluster setup with 4 shards and 4 replicas on a
>> legacy stack.
>> Same machines have been used to host 5 Zookeeper nodes ensemble.
>>
>> Solr version : 4.8.1
>> ZK version : 3.4.6
>>
>> Few days back, one of the solr processes was stuck because of which reads
>> and write were failing. We did a few rounds of ZK/Solr restarts after
>> clearing up disk space and read operations started working fine. but , the
>> write operations (indexing) started failing with below error :
>>
>> Caused by:
>> org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
>> ClusterState says we are the leader (:/solr/),
>> but locally we don't think so. Request came from null
>>
>> We checked the cluster state using below steps. (Solr UI is not
>> accessible for some reasons)
>>
>>
>>1. Go to the path "zookeeper/installation/directory/bin"
>>2. ./zkCli.sh -server localhost:1234
>>3. get /clusterstate.json
>>
>>
>> We see that 3 shard replica nodes are STUCK in 'recovering' state.
>>
>> The cluster is of critical importance and We want to use minimum possible
>> and safe changes to bring cluster back to stable state. Upgrading versions
>> is not possible either.
>>
>>
>> Please help us understand this behavior and way out of it.
>> Fixing this issue is really critical and urgent and we don't have enough
>> Solr expertise in the team.
>> This cluster was mainly in maintenance mode and in a deprecation path,
>> hence the situation.
>>
>> Is there a way to force replication to unstable node from stable node?
>> Please let me know of your thoughts. Really appreciate any help.
>>
>> Thanks,
>> Sarthak
>>
>

Solr 9.7.0 Release Date

[Himanshu Soni]

Dear Solr Team,

I am reaching out to gather information regarding the release date of Solr
version 9.7.0. Our team is particularly interested in the new security
updates and fixes for vulnerabilities that this upcoming version is
expected to include. Understanding the release timing will greatly assist
us in planning our development and update cycles more effectively.

Could you please provide any available details on when Solr 9.7.0 is
anticipated to be released? Additionally, if there are any preliminary
release notes or documentation regarding the security enhancements, it
would be immensely helpful for our preparations.

Thank you for your dedication to improving Solr and maintaining its robust
security framework. We look forward to your response and to the continued
enhancements in the new version.

Best regards,

Himanshu Soni

Solr parsing query: Non ended comments inside comment does not work as expected

[Runar Espeland]

Solr parsing non-ended comments inside comment, does not work as expected.
If there are non-ended comments inside a comment. Then it will treat trailing 
words as comments

Examples
samsung /* Motorola iphone */  -- > works. As expected
samsung /* motorola /* iphone */ ) -->  works.   Not as expected. Ignores 
trailing ')'
( samsung /* motorola /* iphone */ nokia ) -- > fails. Not as expected.  
Because of starting '('.  Ended ')' is ignored. Since it is read as a comment.


Is this a bug ?

Versions:
Solr-spec 8.11.1
Lucene-spec 8.11.1

Solr [3 nodes]/Zk [3nodes] GCP VM Setup with PD-SSD Disk || Indexing is taking 2 hours for 47 GB of data

[Sathish Ponnusamy]

Hi Team,



I am trying to setup solr(3 nodes) and zk(3 nodes) in GCP environment. All
the setup looks okay but except while indexing the data which is taking a
lot of time.



Below is the machine configuration and I already configured and loaded the
data into the local disk of one of the solr nodes before starting the
indexing  of the data into Solr cluster. The home directory of the solr is
in the pd-ssd persistent disk. And the index is also stored in the
Persistent disk.



*Solr nodes [3 nodes]:*

1.   c3d-highmem-16, local disk – 100GB [PD-SSD, Ephemeral], Persistent
disk [PD-SSD, 2000 GB]

2.   Solr version – 9.6.0, Java version -11, LuceneMatchVersion 9.9,

1.   9 shards,

2.   2 replication factor,

3.   JVM memory – 12G

4.   Autocommit/maxtime =  30

5.   Autosoftcommit/maxtime = 12

6.   Each document of the collection may be ~ 2kb size in json format



*ZK nodes [3 nodes]:*

1.   c3d-highcpu -4, local disk – 100GB [PD-SSD, Ephemeral], Persistent
disk [PD-SSD, 2000 GB]

2.   Zk version – 3.9.2, Java version -11


While ingesting the data into solr index noticed the CPU utilization &
memory is normal



Already tried below options from disk side:



1.  
https://cloud.google.com/compute/docs/disks/optimizing-pd-performance#no-ext3

2.  
https://cloud.google.com/compute/docs/disks/optimizing-pd-performance#formatting_parameters



Please let me know the way to increase the performance of solr indexing and
reduce the indexing hours.



Regards

Sathish P

Sathish Ponnusamy

Chennai
m: + 91 9962331981
e: sathishrp...@gmail.com

GitHub - github.com/sathishrpt24
 [image: Youtbue icon]

Zookeeper 3.8.3 FAILED TO START.... but why?

[Peter Johnson]

Hello,
Trying this 'send mail to list option' to try and find out why my new Zookeeper 
3.8.3 app wouldn't  start, I get:
./zkServer.sh start
ZooKeeper JMX enabled by default
Using config: /apps/solr/apache-zookeeper-3.8.3/bin/../conf/zoo.cfg
Starting zookeeper ... FAILED TO START

...and that's all the information there is, so I have nothing to go on.

Bottom-line, I want the bare minimum Zookeeper/Solr installation possible on 1 
server (and not really interested in learning too much about it), I just need 
it as a requirement for OT TeamSite.
With that in mind, I followed these basic steps (which had worked in the past, 
but maybe there is something new):
Setup Zookeeper

  *   cd apache-zookeeper-3.8.3/conf/
  *   mv zoo_sample.cfg zoo.cfg
  *   edit zoo.cfg to change default data dir to /apps/solr/logs/zookeeper
  *   ...and added line: 4lw.commands.whitelist=mntr,conf,ruok
Setup Solr

  *   Rename solr-8.11.2 directory to solr.
  *   cd solr
  *   mkdir cloud/node1/solr
  *   mkdir cloud/node2/solr
  *   cd to dir with solr.xml
  *   cp -p solr.xml ../../cloud/node1/solr/.
  *   cp -p solr.xml ../../cloud/node2/solr/.

Setup Env Vars

  *   export JAVA_HOME=/usr/lib/jvm/jdk-11.0.19+7
  *   export PATH=$JAVA_HOME/bin:$PATH
  *   export SOLR_JAVA_HOME=/usr/lib/jvm/jdk-11.0.19+7

Start servers in same session as env vars set:
/apps/solr/apache-zookeeper-3.8.3/bin/zkServer.sh start

Can anybody tell me what is missing?

Thanks & Regards
Peter Johnson [c]
System Engineer (TeamSite)
Kaiser Permanente

NOTICE TO RECIPIENT:  If you are not the intended recipient of this e-mail, you 
are prohibited from sharing, copying, or otherwise using or disclosing its 
contents.  If you have received this e-mail in error, please notify the sender 
immediately by reply e-mail and permanently delete this e-mail and any 
attachments without reading, forwarding or saving them. v.173.295  Thank you.

AW: TimeZones

[Dario.Viva]

Small correction:
> This will now be 1 day off for all future winter months that are preceded by 
> a 30 day month, and 2 days and 1 hours off for all summer months preceded by 
> a 31 day month.

Not that it matters all too much.

Von: Viva Dario
Gesendet: Donnerstag, 16. Mai 12024 19:30
An: users@solr.apache.org
Betreff: TimeZones

Dear Solr Team,

One use case we have with solr (we use 9.5) is to facet over months on a 
specific fields in our documents. We want to know how many documents there are 
each Month.
But as you probably have guessed, the users of our app don't life in Greenwich 
(also their time changes two times a year ... yuck ...)
So what we would need is to have the ability to get range facets but using 
another timezone.
One simple way that one would probably try first is the following:



GET 
https:///solr//query
Accept: application/json
Content-Type: application/json

{
"query": "*:*",
"limit": 0,
"facet": {
   "series": {
  "field": "",
  "gap": "+1MONTH",
  "start": "2023-12-31T23:00:00Z/MONTH",
  "end": " 2024-04-30T22:00:00Z",
  "type": "range",
"time-zone": "America/Los_Angeles"
   }
}
}


This will obviously not work, as Solr calculates dates using UTC, and thus has 
no idea that 23:00 is actually midnight. It will continue to use 23:00 even for 
summer months (when some weird people have decided that in the summer midnight 
should be at 22:00 UTC). That's not what we want.
But even more drastically, the first time February comes along, all precision 
concerning date calculations jump out the window for good, as solr will now 
continue to use the 29th 23:00 as the starting point for every month after it. 
This will now be 1 day and 1 hour off for all future winter months that are 
preceded by a 30 day month, and 2 days and 2 hours off for all summer months 
preceded by a 31 day month. As 2024 is a leap year the problem is huge, but not 
colossal as it would be in most other years where February only has 28 days.
This is what we get (which is, as I have described, not what one would want to 
get)


{
   "responseHeader": {
  "zkConnected": true,
  "status": 0,
  "QTime": 13,
  "params": {
"json": ""
  }
   },
   "response": {
  "numFound": 2392751,
  "start": 0,
  "maxScore": 1.0,
  "numFoundExact": true,
  "docs": []
   },
   "facets": {
  "count": 2392751,
  "series": {
"buckets": [
   {
  
"val": "2023-12-31T23:00:00Z",
  
"count": 20749
   },
   {
  
"val": "2024-01-31T23:00:00Z",
  
"count": 18716
   },
   {
  
"val": "2024-02-29T23:00:00Z",
  
"count": 19230
   },
   {
  
"val": "2024-03-29T23:00:00Z",
  
"count": 19788
   },
   {
  
"val": "2024-04-29T23:00:00Z",
  
"count": 9215
   }
]
  }
   }
}


So the solution would be to use TZ as described in 
https://solr.apache.org/guide/solr/9_5/indexing-guide/date-formatting-math.html#tz
But somehow this does not work as advertised. It wrongly returns starting 
points in the perspective of utc aka: 00:00:00Z instead of 23:00:00Z) . In your 
example where you use America/Los_Angeles it 

TimeZones

[Dario.Viva]

Dear Solr Team,

One use case we have with solr (we use 9.5) is to facet over months on a 
specific fields in our documents. We want to know how many documents there are 
each Month.
But as you probably have guessed, the users of our app don't life in Greenwich 
(also their time changes two times a year ... yuck ...)
So what we would need is to have the ability to get range facets but using 
another timezone.
One simple way that one would probably try first is the following:



GET https:///solr//query
Accept: application/json
Content-Type: application/json

{
"query": "*:*",
"limit": 0,
"facet": {
   "series": {
  "field": "",
  "gap": "+1MONTH",
  "start": "2023-12-31T23:00:00Z/MONTH",
  "end": " 2024-04-30T22:00:00Z",
  "type": "range",
"time-zone": "America/Los_Angeles"
   }
}
}


This will obviously not work, as Solr calculates dates using UTC, and thus has 
no idea that 23:00 is actually midnight. It will continue to use 23:00 even for 
summer months (when some weird people have decided that in the summer midnight 
should be at 22:00 UTC). That's not what we want.
But even more drastically, the first time February comes along, all precision 
concerning date calculations jump out the window for good, as solr will now 
continue to use the 29th 23:00 as the starting point for every month after it. 
This will now be 1 day and 1 hour off for all future winter months that are 
preceded by a 30 day month, and 2 days and 2 hours off for all summer months 
preceded by a 31 day month. As 2024 is a leap year the problem is huge, but not 
colossal as it would be in most other years where February only has 28 days.
This is what we get (which is, as I have described, not what one would want to 
get)


{
   "responseHeader": {
  "zkConnected": true,
  "status": 0,
  "QTime": 13,
  "params": {
"json": ""
  }
   },
   "response": {
  "numFound": 2392751,
  "start": 0,
  "maxScore": 1.0,
  "numFoundExact": true,
  "docs": []
   },
   "facets": {
  "count": 2392751,
  "series": {
"buckets": [
   {
  
"val": "2023-12-31T23:00:00Z",
  
"count": 20749
   },
   {
  
"val": "2024-01-31T23:00:00Z",
  
"count": 18716
   },
   {
  
"val": "2024-02-29T23:00:00Z",
  
"count": 19230
   },
   {
  
"val": "2024-03-29T23:00:00Z",
  
"count": 19788
   },
   {
  
"val": "2024-04-29T23:00:00Z",
  
"count": 9215
   }
]
  }
   }
}


So the solution would be to use TZ as described in 
https://solr.apache.org/guide/solr/9_5/indexing-guide/date-formatting-math.html#tz
But somehow this does not work as advertised. It wrongly returns starting 
points in the perspective of utc aka: 00:00:00Z instead of 23:00:00Z) . In your 
example where you use America/Los_Angeles it shows that it correctly uses 
2013-11-01T07:00:00Z and so on. I strongly suspect that this is called 
differently in the json api (considering "q" becomes "query" in the json api)



GET https:///solr//query
Accept: application/json
Content-Type: application/json

{
"query": "*:*",
"limit": 0,
"facet": {
   "series": {
  "hardend": false,
  "field": "",

Re:Problems migrating solrj to run with SpringBoot 3

[Luke Kot-Zaniewski (BLOOMBERG/ 919 3RD A)]

Hard to say without seeing your project but jetty seems to be using slf4j as of 
some time 
https://github.com/jetty/jetty.project/blob/7d264e6024efc80124592124891fb6e25b1554af/jetty-core/jetty-http2/jetty-http2-hpack/src/main/java/org/eclipse/jetty/http2/hpack/HpackEncoder.java#L43
 so I'd first check if you can just solve this by upgrading.

This might help give some context to what happened to jetty's logging impl 
https://github.com/jetty/jetty.project/pull/4643

Keep in mind that spring boot can be opinionated about logging depending on 
which starter you use 
https://docs.spring.io/spring-boot/docs/2.0.x/reference/html/howto-logging.html#howto-logging
 .. If the version of Jetty you are running against is linking through an slf4j 
interface (as it has been for some time apparently) then you should be able to 
use a different/more modern logging implementation (i.e. Logback) and manage 
all of that just by adding the right dependency.

Luke

From: users@solr.apache.org At: 05/16/24 12:41:05 UTC-4:00To:  
users@solr.apache.org
Subject: Problems migrating solrj to run with SpringBoot 3

I'm in the process of upgrading a project that uses SolrJ to run with Spring 
Boot 3.  I've been able to keep the current version of my jars after migrating 
to SpringBoot 3.   SolrJ is working in some cases, but I've run into a problem 
where it is missing the logging class for Jetty.  I get this stack trace:


java.lang.ExceptionInInitializerError: Exception 
java.lang.NoClassDefFoundError: org/eclipse/jetty/util/log/Log [in thread 
"http-nio-8080-exec-8"]

   at 
org.eclipse.jetty.http2.hpack.HpackEncoder.(HpackEncoder.java:48)

   at 
org.eclipse.jetty.http2.hpack.HpackFieldPreEncoder.getEncodedField(HpackFieldPre
Encoder.java:45)

   at 
org.eclipse.jetty.http.PreEncodedHttpField.(PreEncodedHttpField.java
:79)

   at 
org.eclipse.jetty.http.PreEncodedHttpField.(PreEncodedHttpField.java
:85)

   at 
org.eclipse.jetty.http.PreEncodedHttpField.(PreEncodedHttpField.java
:90)

   at org.eclipse.jetty.http.HttpFields.(HttpFields.java:48)

   at 
org.eclipse.jetty.client.transport.HttpRequest.(HttpRequest.java:68)

   at 
org.eclipse.jetty.client.HttpClient.newHttpRequest(HttpClient.java:449)

   at org.eclipse.jetty.client.HttpClient.newRequest(HttpClient.java:439)

   at 
org.springframework.http.client.JettyClientHttpRequestFactory.createRequest(Jett
yClientHttpRequestFactory.java:135)

I've looked high and low to find this class.   I would hope that it would have 
been embedded in the SolrJ jar, but apparently not.  I'm using this version of 
Solrj:


  

  org.apache.solr

  solr-solrj

  8.11.3

  

Along with

  

 org.springframework.boot

 spring-boot-starter-data-solr

 2.4.7

  

That is part of SpringBoot.

As far as I can tell, the only difference in the build is the version of 
SpringBoot libraries.

Any Ideas?

Thank you so much for your help.

Todd Stevenson


NOTICE: This e-mail is for the sole use of the intended recipient and may 
contain confidential and privileged information. If you are not the intended 
recipient, you are prohibited from reviewing, using, disclosing or distributing 
this e-mail or its contents. If you have received this e-mail in error, please 
contact the sender by reply e-mail and destroy all copies of this e-mail and 
its contents.

Problems migrating solrj to run with SpringBoot 3

[Todd Stevenson]

I'm in the process of upgrading a project that uses SolrJ to run with Spring 
Boot 3.  I've been able to keep the current version of my jars after migrating 
to SpringBoot 3.   SolrJ is working in some cases, but I've run into a problem 
where it is missing the logging class for Jetty.  I get this stack trace:


java.lang.ExceptionInInitializerError: Exception 
java.lang.NoClassDefFoundError: org/eclipse/jetty/util/log/Log [in thread 
"http-nio-8080-exec-8"]

   at 
org.eclipse.jetty.http2.hpack.HpackEncoder.(HpackEncoder.java:48)

   at 
org.eclipse.jetty.http2.hpack.HpackFieldPreEncoder.getEncodedField(HpackFieldPreEncoder.java:45)

   at 
org.eclipse.jetty.http.PreEncodedHttpField.(PreEncodedHttpField.java:79)

   at 
org.eclipse.jetty.http.PreEncodedHttpField.(PreEncodedHttpField.java:85)

   at 
org.eclipse.jetty.http.PreEncodedHttpField.(PreEncodedHttpField.java:90)

   at org.eclipse.jetty.http.HttpFields.(HttpFields.java:48)

   at 
org.eclipse.jetty.client.transport.HttpRequest.(HttpRequest.java:68)

   at 
org.eclipse.jetty.client.HttpClient.newHttpRequest(HttpClient.java:449)

   at org.eclipse.jetty.client.HttpClient.newRequest(HttpClient.java:439)

   at 
org.springframework.http.client.JettyClientHttpRequestFactory.createRequest(JettyClientHttpRequestFactory.java:135)

I've looked high and low to find this class.   I would hope that it would have 
been embedded in the SolrJ jar, but apparently not.  I'm using this version of 
Solrj:


  

  org.apache.solr

  solr-solrj

  8.11.3

  

Along with

  

 org.springframework.boot

 spring-boot-starter-data-solr

 2.4.7

  

That is part of SpringBoot.

As far as I can tell, the only difference in the build is the version of 
SpringBoot libraries.

Any Ideas?

Thank you so much for your help.

Todd Stevenson


NOTICE: This e-mail is for the sole use of the intended recipient and may 
contain confidential and privileged information. If you are not the intended 
recipient, you are prohibited from reviewing, using, disclosing or distributing 
this e-mail or its contents. If you have received this e-mail in error, please 
contact the sender by reply e-mail and destroy all copies of this e-mail and 
its contents.

Re: Number searches returning decimals

[Charlie Hull]

Hi Kem,

Each field in your schema will have an associated type. It might be 
useful to look at some of the examples supplied with Solr to understand 
in more depth how this works, or go through the tutorials 
https://solr.apache.org/guide/solr/latest/getting-started/solr-tutorial.html


There's also some training available for Solr - I wrote about this here:
https://opensourceconnections.com/blog/2023/02/14/how-to-train-a-search-team-and-what-does-it-cost/

Cheers

Charlie

On 15/05/2024 23:24, Kemberli Holmes wrote:

Hi Charlie,

Thanks for your response. I am reading over the material you recommended.
I am a novice to Solr.  There are several analysis chains defined in my
schema.xml.  They all have a fieldType name that starts with "text".  How
can I tell which one is being used?

Thanks,
Kem

On Wed, May 15, 2024, 8:05 AM Charlie Hull 
wrote:


Whatever analysis chain you're using to turn your source data and/or
queries into a normalised form is stripping out the decimal point.

https://solr.apache.org/guide/solr/latest/indexing-guide/document-analysis.html
explains how this works and

https://solr.apache.org/guide/solr/latest/indexing-guide/analysis-screen.html
will show what is actually happening in your index.

Cheers

Charlie

On 14/05/2024 21:04, Kemberli Holmes wrote:

Hello,

We are running ColdFusion 2021 and were looking for some help with Solr

and

number searches.  When users search for a number such as 23019, decimals
such as 230.19 are returned.  Another example is a search on 3373.  A

file

with 33.73 was returned.  We would like to only get results that have

that

exact number in it—23019 or 3373.  Can you help us with the

configuration?

A third example is a search on 901 is returning files with 90.1 in it.

But

we just want hits that say 901.   We are using Solr 7.2.1.


Thanks,

Kem


--
Charlie Hull - Managing Consultant at OpenSource Connections Limited
Founding member of The Search Network and co-author of Searching the
Enterprise
tel/fax: +44 (0)8700 118334
mobile: +44 (0)7767 825828

OpenSource Connections Europe GmbH | Pappelallee 78/79 | 10437 Berlin
Amtsgericht Charlottenburg | HRB 230712 B
Geschäftsführer: John M. Woodell | David E. Pugh
Finanzamt: Berlin Finanzamt für Körperschaften II



--
Charlie Hull - Managing Consultant at OpenSource Connections Limited
Founding member of The Search Network and co-author of Searching the Enterprise
tel/fax: +44 (0)8700 118334
mobile: +44 (0)7767 825828

OpenSource Connections Europe GmbH | Pappelallee 78/79 | 10437 Berlin
Amtsgericht Charlottenburg | HRB 230712 B
Geschäftsführer: John M. Woodell | David E. Pugh
Finanzamt: Berlin Finanzamt für Körperschaften II