date:20221013

Re: Solr 9 and the Affinity placement plugin

2022-10-13 Thread Jan Høydahl

Hi,

In Solr 9 the focus is on a rich Java API that will allow you to create your 
own placement plugin that can do pretty much anything.
The affinity plugin tries to give a good OOTB experience for most use cases, 
but does not aim to be the one everyone uses.
You may want to fork the affinity plugin and extend it with your needs. If you 
believe your extension is useful to a larger audience you may consider opening 
a PR with your changes.

Jan

> 12. okt. 2022 kl. 16:05 skrev Jonathan Tan :
> 
> Hi!
> 
> In Solr 8.6, I used the autoscaling configuration to set it up so that we
> had 2 `nodeTypes`, one for indexing, the other for querying.
> And our collections were set up to be TLOG + PULL replicas only, and we'd
> use the autoscaling to place the TLOG on the indexing nodeTypes, and the
> PULL on the querying nodeTypes. (Essentially replicating the older
> master/slave setup of pre-SolrCloud)
> 
> Now we've come to Solr 9, and I can't really find a clear way to do the
> same thing.
> 
> https://solr.apache.org/guide/solr/latest/configuration-guide/replica-placement-plugins.html#affinityplacementfactory
> 
> I've looked through this, and it seems to imply that the
> `collectionNodeType` configuration will allow me to place specific
> collections on specific nodeTypes. But I can't find a way to place specific
> replica types on specific nodeTypes...
> 
> Is this mechanism no longer existing?
> 
> Thank you
> Jonathan

Re: solr 9 standalone crashed after few hours - PhaseIdealLoop::build_loop_late_post_work

2022-10-13 Thread Tomasz Elendt

We encountered the same bug in SolrCloud deployment on our staging environment. 
We run Solr in Kubernetes and we use the official solr:9.0.0 docker image.

If this is a know bug in JDK that especially affects Lucene projects (and by 
proxy, Solr) why does the official Solr image use Java 17?

Tomasz

> On 11. Oct 2022, at 15:27, Kevin Risden  wrote:
> 
> https://lists.apache.org/thread/tbjljn512k8srtgr5f4tb2q6dmq1z515
> 
> This same issue was found in Lucene back in May and there was a JDK bug
> opened about it. I think https://bugs.openjdk.org/browse/JDK-8285835 is
> tracking this currently.
> 
> Kevin Risden
> 
> 
> On Mon, Oct 10, 2022 at 9:41 PM dmitri maziuk 
> wrote:
> 
>> On 2022-10-10 4:58 PM, Jen-Ya Ku wrote:
>>> Hi all,
>>> 
>>> We've deployed solr9 on OpenJDK 17 and it crashed after few hours with
>>> following error:
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  SIGSEGV (0xb) at pc=0x7f834389b332, pid=8997, tid=9025
>> 
>> What are you running it on? -- E.g. some SuperMicro motherboards ship
>> with fan speed set to "balanced" in the BIOS and have no thermal sensors
>> under the RAM banks. Can you guess what happens when a memory-intensive
>> job comes along and runs long enough for the SIMMS to heat up?
>> 
>> Dima
>> 
>>

Solr SSL Troublshooting

2022-10-13 Thread Rayner, June

Hi Folks

We are following the steps in the Securing Solr
document to enable SSL
for our Solr 8.11 installation. We generated the certificate and a key,
and updated the solr.in.sh file to enable the SSL related system properties.
When we restart Solr with SSL enabled, the log file shows that it's reading
the keystore.p12 that we created and there are no error messages in the Solr
log file, but we can't access the Solr Admin page.

In the Solr logs, we don't see any error messages, the only thing we see is two
warning level messages

o.e.j.u.s.S.config No Client EndPointIdentificationAlgorithm configured for
Client@4c1bdcc2[provider=null,keyStore=file:///opt/solr-8.11.1/server/etc/solr-ssl.keystore.p12,trustStore=file:///opt/solr-8.11.1/server/etc/solr-ssl

2022-09-02 14:08:41.696 WARN (main) [ ] o.a.s.c.CoreContainer Not all
security plugins configured! authentication=disabled authorization=disabled.
Solr is only as secure as you make it. Consider configuring
authentication/authorization before exposing Solr to users

Can anyone suggest some next troubleshooting steps? Is there a problem
with the certificate itself?

Regards,

June Rayner
eiNetwork
rayn...@einetwork.net

The information contained in this e-mail, and any attachment, is confidential
and is intended solely for the use of the intended recipient. Access, copying
or re-use of the e-mail or any attachment, or any information contained
therein, by any other person is not authorized. If you are not the intended
recipient please return the e-mail to the sender and delete it from your
computer. Although we attempt to sweep e-mail and attachments for viruses, we
do not guarantee that either are virus-free and accept no liability for any
damage sustained as a result of viruses.

Re: Solr SSL Troublshooting

2022-10-13 Thread Jan Høydahl

>  but we can't access the Solr Admin page.


What exactly does this mean?
Do you see the last line Jetty prints out in the log that it is listening to 
port 8983?
What happens when you try to connect to the port, with e.g. cURL?

Jan

RE: Solr SSL Troublshooting

2022-10-13 Thread Rayner, June

Hi Jan

Thanks for your response. With the SSL configured,

we get an ERR_INVALID_HTTP_RESPONSE error when we access the solr admin URL in 
a browser

with cURL, we get the following
curl localhost:8080/solr/#/dogs/query
curl: (1) Received HTTP/0.9 when not allowed

There are 2 lines in the solr log that mention the Solr port
cat solr.log | grep 8080
2022-10-13 16:32:56.616 INFO  (main) [   ] o.a.s.s.SolrDispatchFilter / __| 
___| |_ _   Starting in standalone mode on port 8080
2022-10-13 16:32:58.339 INFO  (main) [   ] o.e.j.s.AbstractConnector Started 
ServerConnector@18245eb0{SSL, (ssl, alpn, h2, http/1.1)}{0.0.0.0:8080}

These are the last lines in the log itself
2022-10-13 16:32:59.268 INFO  
(searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio] 
o.a.s.c.QuerySenderListener QuerySenderListener done.
2022-10-13 16:32:59.268 INFO  
(searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio] 
o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker: default
2022-10-13 16:32:59.269 INFO  
(searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2] 
o.a.s.c.S.Request [biblio2]  webapp=null path=null 
params={q=science+art+business+engineering+history&facet.field=format&distrib=false&fq=format:book&event=firstSearcher}
 hits=0 status=0 QTime=98
2022-10-13 16:32:59.269 INFO  
(searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2] 
o.a.s.c.QuerySenderListener QuerySenderListener done.
2022-10-13 16:32:59.271 INFO  
(searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2] 
o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker: default
2022-10-13 16:32:59.301 INFO  
(searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio] 
o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker: basicSpell
2022-10-13 16:32:59.304 INFO  
(searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2] 
o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker: basicSpell
2022-10-13 16:32:59.324 INFO  
(searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio] 
o.a.s.c.SolrCore [biblio]  Registered new searcher autowarm time: 0 ms
2022-10-13 16:32:59.328 INFO  
(searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2] 
o.a.s.c.SolrCore [biblio2]  Registered new searcher autowarm time: 0 ms

Regards,

June


-Original Message-
From: Jan Høydahl 
Sent: Thursday, October 13, 2022 11:36 AM
To: users@solr.apache.org
Subject: Re: Solr SSL Troublshooting

>  but we can't access the Solr Admin page.


What exactly does this mean?
Do you see the last line Jetty prints out in the log that it is listening to 
port 8983?
What happens when you try to connect to the port, with e.g. cURL?

Jan

The information contained in this e-mail, and any attachment, is confidential 
and is intended solely for the use of the intended recipient. Access, copying 
or re-use of the e-mail or any attachment, or any information contained 
therein, by any other person is not authorized. If you are not the intended 
recipient please return the e-mail to the sender and delete it from your 
computer. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that either are virus-free and accept no liability for any 
damage sustained as a result of viruses.

Re: Solr SSL Troublshooting

2022-10-13 Thread Anshum Gupta

How are you starting Solr? Seems like you're running it in standalone mode,
can you please confirm?

On Thu, Oct 13, 2022 at 9:44 AM Rayner, June  wrote:

> Hi Jan
>
> Thanks for your response. With the SSL configured,
>
> we get an ERR_INVALID_HTTP_RESPONSE error when we access the solr admin
> URL in a browser
>
> with cURL, we get the following
> curl localhost:8080/solr/#/dogs/query
> curl: (1) Received HTTP/0.9 when not allowed
>
> There are 2 lines in the solr log that mention the Solr port
> cat solr.log | grep 8080
> 2022-10-13 16:32:56.616 INFO  (main) [   ] o.a.s.s.SolrDispatchFilter /
> __| ___| |_ _   Starting in standalone mode on port 8080
> 2022-10-13 16:32:58.339 INFO  (main) [   ] o.e.j.s.AbstractConnector
> Started ServerConnector@18245eb0{SSL, (ssl, alpn, h2, http/1.1)}{
> 0.0.0.0:8080}
>
> These are the last lines in the log itself
> 2022-10-13 16:32:59.268 INFO
> (searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio]
> o.a.s.c.QuerySenderListener QuerySenderListener done.
> 2022-10-13 16:32:59.268 INFO
> (searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio]
> o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker: default
> 2022-10-13 16:32:59.269 INFO
> (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> o.a.s.c.S.Request [biblio2]  webapp=null path=null
> params={q=science+art+business+engineering+history&facet.field=format&distrib=false&fq=format:book&event=firstSearcher}
> hits=0 status=0 QTime=98
> 2022-10-13 16:32:59.269 INFO
> (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> o.a.s.c.QuerySenderListener QuerySenderListener done.
> 2022-10-13 16:32:59.271 INFO
> (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker: default
> 2022-10-13 16:32:59.301 INFO
> (searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio]
> o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker:
> basicSpell
> 2022-10-13 16:32:59.304 INFO
> (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker:
> basicSpell
> 2022-10-13 16:32:59.324 INFO
> (searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio]
> o.a.s.c.SolrCore [biblio]  Registered new searcher autowarm time: 0 ms
> 2022-10-13 16:32:59.328 INFO
> (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> o.a.s.c.SolrCore [biblio2]  Registered new searcher autowarm time: 0 ms
>
> Regards,
>
> June
>
>
> -Original Message-
> From: Jan Høydahl 
> Sent: Thursday, October 13, 2022 11:36 AM
> To: users@solr.apache.org
> Subject: Re: Solr SSL Troublshooting
>
> >  but we can't access the Solr Admin page.
>
>
> What exactly does this mean?
> Do you see the last line Jetty prints out in the log that it is listening
> to port 8983?
> What happens when you try to connect to the port, with e.g. cURL?
>
> Jan
>
> The information contained in this e-mail, and any attachment, is
> confidential and is intended solely for the use of the intended recipient.
> Access, copying or re-use of the e-mail or any attachment, or any
> information contained therein, by any other person is not authorized. If
> you are not the intended recipient please return the e-mail to the sender
> and delete it from your computer. Although we attempt to sweep e-mail and
> attachments for viruses, we do not guarantee that either are virus-free and
> accept no liability for any damage sustained as a result of viruses.
>


-- 
Anshum Gupta

Script Update Processor

2022-10-13 Thread Matthew Castrigno

Hello community, Let me thank you in advance for any insights you can share.

I am attempting to use the Script Update Processor as described here:
https://solr.apache.org/guide/solr/latest/configuration-guide/script-update-processor.html#javascript

This works fine however I am attempting to use it to format a payload that is 
not something formatted into fields quite right.

If I log cmd.solrDoc does not get the raw stream.

Is there some way to get the raw payload so that I can process it?

Thank you so much!

--
"This message is intended for the use of the person or entity to which it is 
addressed and may contain information that is confidential or privileged, the 
disclosure of which is governed by applicable law. If the reader of this 
message is not the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this information is strictly 
prohibited. If you have received this message by error, please notify us 
immediately and destroy the related message."

Re: Script Update Processor

2022-10-13 Thread Matthew Castrigno

Actually, it is the raw payload but has inserted  at what appears to be 
after every ","
Strange I suppose I can strip those without harm.

From: Matthew Castrigno 
Sent: Thursday, October 13, 2022 11:13 AM
To: users@solr.apache.org 
Subject: Script Update Processor

Hello community, Let me thank you in advance for any insights you can share. I 
am attempting to use the Script Update Processor as described here: https: 
//urldefense. com/v3/__https: //solr. apache. 
org/guide/solr/latest/configuration-guide/script-update-processor. 
html*javascript__;Iw!!FkC3_z_N!JNiQanjccEAL2TcAajCXXJQUseVuqdoEYjAv4IrEVhDh-VeUmbJL8ZqS8nr_wr55kX4OrDdYOP7k_A$
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the St. Luke's email system.

ZjQcmQRYFpfptBannerEnd

Hello community, Let me thank you in advance for any insights you can share.

I am attempting to use the Script Update Processor as described here:
https://urldefense.com/v3/__https://solr.apache.org/guide/solr/latest/configuration-guide/script-update-processor.html*javascript__;Iw!!FkC3_z_N!JNiQanjccEAL2TcAajCXXJQUseVuqdoEYjAv4IrEVhDh-VeUmbJL8ZqS8nr_wr55kX4OrDdYOP7k_A$

This works fine however I am attempting to use it to format a payload that is 
not something formatted into fields quite right.

If I log cmd.solrDoc does not get the raw stream.

Is there some way to get the raw payload so that I can process it?

Thank you so much!

--
"This message is intended for the use of the person or entity to which it is 
addressed and may contain information that is confidential or privileged, the 
disclosure of which is governed by applicable law. If the reader of this 
message is not the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this information is strictly 
prohibited. If you have received this message by error, please notify us 
immediately and destroy the related message."

--
"This message is intended for the use of the person or entity to which it is 
addressed and may contain information that is confidential or privileged, the 
disclosure of which is governed by applicable law. If the reader of this 
message is not the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this information is strictly 
prohibited. If you have received this message by error, please notify us 
immediately and destroy the related message."

Re: solr 9 standalone crashed after few hours - PhaseIdealLoop::build_loop_late_post_work

2022-10-13 Thread solr

Hi.

We tried to upgrade a number of solar images from 8.11 to 9.0.0 this week and 
ran into the same problems with the official docker image as well 
(approximately 30 running pods in Kubernetes, crashing on average once an hour).

We even tried to build a docker image with another base image 
(bellsoft/liberica-openjdk-debian:17), with the same result (even though the 
actual error differed somewhat (optimize instead of build_loop_late_post_work)).

For now we ended up with building a docker image of solr 9.0.0 based on 
openjdk:11-jre and it has been running several hours without crashes.  Maybe 
the official docker image should be reverted to this until the bug is fixed?


For reference: here are 2 crashes (hs_err_pidXX.log and replay_pidXX.log can be 
provided on request):


Temurin-17.0.4.1+1:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7fd81c7e6153, pid=14, tid=85
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.4.1+1 (17.0.4.1+1) 
(build 17.0.4.1+1)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.4.1+1 (17.0.4.1+1, mixed mode, 
sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xacc153]  PhaseIdealLoop::build_loop_late_post_work(Node*, 
bool)+0x153
#
# Core dump will be written. Default location: /core.%e.14.%t
#
# An error report file with more information is saved as:
# /opt/solr-9.0.0/server/hs_err_pid14.log
{#
# Compiler replay data is saved as:
# /opt/solr-9.0.0/server/replay_pid14.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
#
/opt/scripts/startSolr.sh: line 54:14 Aborted 
/opt/solr/bin/solr -f -p ${solrport} -m ${memory} 
-Dsolr.jetty.request.header.size=65535 -Dsolr.disable.allowUrls=true 
-Dsolrindex=${profile} -Dlog4j2.formatMsgNoLookups=true -Dfinnapp=${finnapp} 
-Dsolr.master.host=${masterhost} -Denable.slave=true -Denable.replication=true 
-Dsolr.http1=true -Dsolr.disable.shardsWhitelist=true 
-Dodin.job.host=solr-cl-job -Dodin.bap.host=solr-cl-bap 
-Dodin.motor.host=solr-cl-motor -Dodin.estate.host=solr-cl-estate


bellsoft/liberica-openjdk-debian:17
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7f96e2515e7f, pid=13, tid=76
#
# JRE version: OpenJDK Runtime Environment (17.0.4.1+1) (build 17.0.4.1+1-LTS)
# Java VM: OpenJDK 64-Bit Server VM (17.0.4.1+1-LTS, mixed mode, tiered, 
compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x515e7f]  PhaseIdealLoop::optimize(PhaseIterGVN&, 
LoopOptsMode)+0x13bf
#
# Core dump will be written. Default location: /core.%e.13.%t
#
# An error report file with more information is saved as:
# /opt/solr-9.0.0/server/hs_err_pid13.log
#
# Compiler replay data is saved as:
# /opt/solr-9.0.0/server/replay_pid13.log
#
# If you would like to submit a bug report, please visit:
#   https://bell-sw.com/support
#
/opt/scripts/startSolr.sh: line 54:13 Aborted 
/opt/solr/bin/solr -f -p ${solrport} -m ${memory} 
-Dsolr.jetty.request.header.size=65535 -Dsolr.disable.allowUrls=true 
-Dsolrindex=${profile} -Dlog4j2.formatMsgNoLookups=true -Dfinnapp=${finnapp} 
-Dsolr.master.host=${masterhost} -Denable.slave=true -Denable.replication=true 
-Dsolr.http1=true -Dsolr.disable.shardsWhitelist=true 
-Dodin.job.host=solr-cl-job -Dodin.bap.host=solr-cl-bap 
-Dodin.motor.host=solr-cl-motor -Dodin.estate.host=solr-cl-estate






Regards,


Fredrik


--

Fredrik Rødland   Cell:+47 99 21 98 17
Maisen Pedersens vei 1Twitter: @fredrikr
NO-1363 Høvik, NORWAY flickr:  
http://www.flickr.com/fmmr/
http://rodland.no about.me http://about.me/fmr

RE: Solr SSL Troublshooting

2022-10-13 Thread Rayner, June

Hi Anshum

Thanks for your response. Yes, we're running Solr standalone

We start Solr as a service.   The startup script uses the following to start 
solr
"/usr/local/vufind-5.0/solr/vendor/bin/solr" "$1" -force -p 8080 -s 
/usr/local/vufind-5.0/solr/vufind -m 4096M -a "-Ddisable.configEdit=true 
-Dsolr.log=/usr/local/vufind-5.0/solr/vufind/logs/jetty

Regards,

June

-Original Message-
From: Anshum Gupta 
Sent: Thursday, October 13, 2022 12:50 PM
To: users@solr.apache.org
Subject: Re: Solr SSL Troublshooting

How are you starting Solr? Seems like you're running it in standalone mode, can 
you please confirm?

On Thu, Oct 13, 2022 at 9:44 AM Rayner, June  wrote:

> Hi Jan
>
> Thanks for your response. With the SSL configured,
>
> we get an ERR_INVALID_HTTP_RESPONSE error when we access the solr
> admin URL in a browser
>
> with cURL, we get the following
> curl localhost:8080/solr/#/dogs/query
> curl: (1) Received HTTP/0.9 when not allowed
>
> There are 2 lines in the solr log that mention the Solr port cat
> solr.log | grep 8080
> 2022-10-13 16:32:56.616 INFO  (main) [   ] o.a.s.s.SolrDispatchFilter /
> __| ___| |_ _   Starting in standalone mode on port 8080
> 2022-10-13 16:32:58.339 INFO  (main) [   ] o.e.j.s.AbstractConnector
> Started ServerConnector@18245eb0{SSL, (ssl, alpn, h2, http/1.1)}{
> 0.0.0.0:8080}
>
> These are the last lines in the log itself
> 2022-10-13 16:32:59.268 INFO
> (searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio]
> o.a.s.c.QuerySenderListener QuerySenderListener done.
> 2022-10-13 16:32:59.268 INFO
> (searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio]
> o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker:
> default
> 2022-10-13 16:32:59.269 INFO
> (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> o.a.s.c.S.Request [biblio2]  webapp=null path=null
> params={q=science+art+business+engineering+history&facet.field=format&
> distrib=false&fq=format:book&event=firstSearcher}
> hits=0 status=0 QTime=98
> 2022-10-13 16:32:59.269 INFO
> (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> o.a.s.c.QuerySenderListener QuerySenderListener done.
> 2022-10-13 16:32:59.271 INFO
> (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker:
> default
> 2022-10-13 16:32:59.301 INFO
> (searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio]
> o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker:
> basicSpell
> 2022-10-13 16:32:59.304 INFO
> (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker:
> basicSpell
> 2022-10-13 16:32:59.324 INFO
> (searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio]
> o.a.s.c.SolrCore [biblio]  Registered new searcher autowarm time: 0 ms
> 2022-10-13 16:32:59.328 INFO
> (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> o.a.s.c.SolrCore [biblio2]  Registered new searcher autowarm time: 0
> ms
>
> Regards,
>
> June
>
>
> -Original Message-
> From: Jan Høydahl 
> Sent: Thursday, October 13, 2022 11:36 AM
> To: users@solr.apache.org
> Subject: Re: Solr SSL Troublshooting
>
> >  but we can't access the Solr Admin page.
>
>
> What exactly does this mean?
> Do you see the last line Jetty prints out in the log that it is
> listening to port 8983?
> What happens when you try to connect to the port, with e.g. cURL?
>
> Jan
>
> The information contained in this e-mail, and any attachment, is
> confidential and is intended solely for the use of the intended recipient.
> Access, copying or re-use of the e-mail or any attachment, or any
> information contained therein, by any other person is not authorized.
> If you are not the intended recipient please return the e-mail to the
> sender and delete it from your computer. Although we attempt to sweep
> e-mail and attachments for viruses, we do not guarantee that either
> are virus-free and accept no liability for any damage sustained as a result 
> of viruses.
>


--
Anshum Gupta
The information contained in this e-mail, and any attachment, is confidential 
and is intended solely for the use of the intended recipient. Access, copying 
or re-use of the e-mail or any attachment, or any information contained 
therein, by any other person is not authorized. If you are not the intended 
recipient please return the e-mail to the sender and delete it from your 
computer. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that either are virus-free and accept no liability for any 
damage sustained as a result of viruses.

Re: Script Update Processor

2022-10-13 Thread dmitri maziuk


On 2022-10-13 12:35 PM, Matthew Castrigno wrote:

Actually, it is the raw payload but has inserted  at what appears to be after every 
","
Strange I suppose I can strip those without harm.


If you look at logging page in Solr admin interface, it'll have them (at 
least in our 6.5.0 and 8.7.0) after every comma as well.


It's a "zero-width space", it has very limited uses and I can't think of 
any rational reason to put one after a comma. I.e. it's got to be a bug.


Dima

Re: Modifying maxFormContentSize in Apache Solr service.

2022-10-13 Thread Kaushal Shriyan

On Wed, Oct 12, 2022 at 9:24 PM Kaushal Shriyan 
wrote:

> Hi,
>
> I am running Apache Solr 8.11.2 on CentOS Linux release 7.9.2009 (Core)
> trying to modify /opt/solr/server/etc/jetty.xml to set the Attribute
> *maxFormContentSize* as per the below path
>
> [root@etc]# ls -l
> total 76
> -rw-r--r-- 1 root root  1950 May 13 03:21 jetty-gzip.xml
> -rw-r--r-- 1 root root  3630 May 13 03:21 jetty-https8.xml
> -rw-r--r-- 1 root root  3698 Oct 12 17:54 jetty-https.xml
> -rw-r--r-- 1 root root  2686 Oct 12 17:53 jetty-http.xml
> -rw-r--r-- 1 root root  1850 May 13 03:21 jetty-requestlog.xml
> -rw-r--r-- 1 root root  2248 May 13 03:21 jetty-ssl.xml
> -rw-r--r-- 1 root root 11646 Oct 12 17:51 jetty.xml
> -rw-r--r-- 1 root root 11823 May 13 03:21 security.policy
> -rw-r--r-- 1 root root  1279 May 13 03:21 security.properties
> -rw-r--r-- 1 root root 24426 May 13 03:21 webdefault.xml
> [root@etc]#
>
> I am adding the below attribute in /opt/solr/server/etc/jetty.xml to
> increase maxFormContentSize
>
> 
>   org.eclipse.jetty.server.Request.maxFormContentSize
>   150
> 
>
> When i restart the solr service it fails with the below message.
>
> [root@etc]# service solr restart
> Sending stop command to Solr running on port 8983 ... waiting up to 180
> seconds to allow Jetty process 4311 to stop gracefully.
> Waiting up to 180 seconds to see Solr running on port 8983 [\]  Still not
> seeing Solr listening on 8983 after 180 seconds!
> 2022-10-12 10:28:25.469 INFO  (main) [   ] o.e.j.u.log Logging initialized
> @2083ms to org.eclipse.jetty.util.log.Slf4jLog
> 2022-10-12 10:28:25.601 WARN  (main) [   ] o.e.j.x.XmlConfiguration Config
> error at 
>  class="com.codahale.metrics.jetty9.InstrumentedQueuedThreadPool"> name="registry">
>  class="com.codahale.metrics.SharedMetricRegistries">solr.jetty
>   
>   
> 2022-10-12 10:28:25.601 WARN  (main) [   ] o.e.j.x.XmlConfiguration  =>
> java.lang.IllegalStateException: Element 'Arg' not skipped
> at
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:507)
> java.lang.IllegalStateException: Element 'Arg' not skipped
> at
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:507)
> ~[jetty-xml-9.4.44.v20210927.jar:9.4.44.v20210927]
> at
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:468)
> ~[jetty-xml-9.4.44.v20210927.jar:9.4.44.v20210927]
> at
> org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:380)
> ~[jetty-xml-9.4.44.v20210927.jar:9.4.44.v20210927]
> at
> org.eclipse.jetty.xml.XmlConfiguration.lambda$main$3(XmlConfiguration.java:1893)
> ~[jetty-xml-9.4.44.v20210927.jar:9.4.44.v20210927]
> at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
> at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1857)
> ~[jetty-xml-9.4.44.v20210927.jar:9.4.44.v20210927]
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:?]
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?]
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
> at org.eclipse.jetty.start.Main.invokeMain(Main.java:218)
> ~[start.jar:9.4.44.v20210927]
> at org.eclipse.jetty.start.Main.start(Main.java:491)
> ~[start.jar:9.4.44.v20210927]
> at org.eclipse.jetty.start.Main.main(Main.java:77)
> ~[start.jar:9.4.44.v20210927]
> [root@etc]#
>
> Am I missing anything? Please guide me to modify maxFormContentSize in
> solr service. Thanks in advance.
>
> Best Regards,
>
> Kaushal
>

Hi,

Checking in again if someone can pitch in for my earlier post to this
mailing list. Thanks in advance.

Best Regards,

Kaushal

Re: solr 9 standalone crashed after few hours - PhaseIdealLoop::build_loop_late_post_work

2022-10-13 Thread Wei

We also observed the same SIGSEGV crash during our test with Solr 9.0.0.
It happens very rarely though,  seem 2 occurences during one month of
testing.  We use Zulu JDK 17.34.


   -

   A fatal error has been detected by the Java Runtime Environment:
   SIGSEGV (0xb) at pc=0x7f96b852d3a1, pid=16597, tid=16637
   # JRE version: OpenJDK Runtime Environment Zulu17.34+20-SA (17.0.3+7)
   (build 17.0.3+7-LTS)
   # Java VM: OpenJDK 64-Bit Server VM Zulu17.34+20-SA (17.0.3+7-LTS, mixed
   mode, sharing, tiered, compressed class ptrs, g1 gc, linux-amd64)
   # Problematic frame:
   # V  [libjvm.so+0x9e13a1]
   PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x111


Do we know which lucene/solr component would trigger this error?

Regards,
Wei

On Thu, Oct 13, 2022 at 10:51 AM solr  wrote:

> Hi.
>
> We tried to upgrade a number of solar images from 8.11 to 9.0.0 this week
> and ran into the same problems with the official docker image as well
> (approximately 30 running pods in Kubernetes, crashing on average once an
> hour).
>
> We even tried to build a docker image with another base image
> (bellsoft/liberica-openjdk-debian:17), with the same result (even though
> the actual error differed somewhat (optimize instead of
> build_loop_late_post_work)).
>
> For now we ended up with building a docker image of solr 9.0.0 based on
> openjdk:11-jre and it has been running several hours without crashes.
> Maybe the official docker image should be reverted to this until the bug is
> fixed?
>
>
> For reference: here are 2 crashes (hs_err_pidXX.log and replay_pidXX.log
> can be provided on request):
>
>
> Temurin-17.0.4.1+1:
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x7fd81c7e6153, pid=14, tid=85
> #
> # JRE version: OpenJDK Runtime Environment Temurin-17.0.4.1+1 (17.0.4.1+1)
> (build 17.0.4.1+1)
> # Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.4.1+1 (17.0.4.1+1, mixed
> mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc,
> linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0xacc153]
> PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x153
> #
> # Core dump will be written. Default location: /core.%e.14.%t
> #
> # An error report file with more information is saved as:
> # /opt/solr-9.0.0/server/hs_err_pid14.log
> {#
> # Compiler replay data is saved as:
> # /opt/solr-9.0.0/server/replay_pid14.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://github.com/adoptium/adoptium-support/issues
> #
> /opt/scripts/startSolr.sh: line 54:14 Aborted
>  /opt/solr/bin/solr -f -p ${solrport} -m ${memory}
> -Dsolr.jetty.request.header.size=65535 -Dsolr.disable.allowUrls=true
> -Dsolrindex=${profile} -Dlog4j2.formatMsgNoLookups=true
> -Dfinnapp=${finnapp} -Dsolr.master.host=${masterhost} -Denable.slave=true
> -Denable.replication=true -Dsolr.http1=true
> -Dsolr.disable.shardsWhitelist=true -Dodin.job.host=solr-cl-job
> -Dodin.bap.host=solr-cl-bap -Dodin.motor.host=solr-cl-motor
> -Dodin.estate.host=solr-cl-estate
>
>
> bellsoft/liberica-openjdk-debian:17
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x7f96e2515e7f, pid=13, tid=76
> #
> # JRE version: OpenJDK Runtime Environment (17.0.4.1+1) (build
> 17.0.4.1+1-LTS)
> # Java VM: OpenJDK 64-Bit Server VM (17.0.4.1+1-LTS, mixed mode, tiered,
> compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x515e7f]  PhaseIdealLoop::optimize(PhaseIterGVN&,
> LoopOptsMode)+0x13bf
> #
> # Core dump will be written. Default location: /core.%e.13.%t
> #
> # An error report file with more information is saved as:
> # /opt/solr-9.0.0/server/hs_err_pid13.log
> #
> # Compiler replay data is saved as:
> # /opt/solr-9.0.0/server/replay_pid13.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bell-sw.com/support
> #
> /opt/scripts/startSolr.sh: line 54:13 Aborted
>  /opt/solr/bin/solr -f -p ${solrport} -m ${memory}
> -Dsolr.jetty.request.header.size=65535 -Dsolr.disable.allowUrls=true
> -Dsolrindex=${profile} -Dlog4j2.formatMsgNoLookups=true
> -Dfinnapp=${finnapp} -Dsolr.master.host=${masterhost} -Denable.slave=true
> -Denable.replication=true -Dsolr.http1=true
> -Dsolr.disable.shardsWhitelist=true -Dodin.job.host=solr-cl-job
> -Dodin.bap.host=solr-cl-bap -Dodin.motor.host=solr-cl-motor
> -Dodin.estate.host=solr-cl-estate
>
>
>
>
>
>
> Regards,
>
>
> Fredrik
>
>
> --
>
> Fredrik Rødland   Cell:+47 99 21 98 17
> Maisen Pedersens vei 1Twitter: @fredrikr
> NO-1363 Høvik, NORWAY flickr:
> http://www.flickr.com/fmmr/
> http://rodland.no about.me http://about.me/fmr
>
>

Re: solr 9 standalone crashed after few hours - PhaseIdealLoop::build_loop_late_post_work

2022-10-13 Thread Wei

Looks our case is triggered from caffeine cache, different from
https://bugs.openjdk.org/browse/JDK-8285835 where it happens in facet
module.


---  T H R E A D  ---


Current thread (0x7f96b1286f40):  JavaThread "C2 CompilerThread0"
daemon [_thread_in_native, id=16637,
stack(0x7f85f50ab000,0x7f85f51ac000)]



Current CompileTask:

C2:148683516 28882   !   4
com.github.benmanes.caffeine.cache.BoundedLocalCache::put
(731 bytes)


Stack: [0x7f85f50ab000,0x7f85f51ac000],  sp=0x7f85f51a6e40,  free
space=1007k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)

V  [libjvm.so+0x9e13a1]  PhaseIdealLoop::build_loop_late_post_work(Node*,
bool)+0x111

V  [libjvm.so+0x9e1910]  PhaseIdealLoop::build_loop_late(VectorSet&,
Node_List&, Node_Stack&)+0x180

V  [libjvm.so+0x9e2321]
PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x841

V  [libjvm.so+0x5b90da]  PhaseIdealLoop::optimize(PhaseIterGVN&,
LoopOptsMode)+0x17a

V  [libjvm.so+0x5b6b5e]  Compile::Optimize()+0x84e

V  [libjvm.so+0x5b883c]  Compile::Compile(ciEnv*, ciMethod*, int, bool,
bool, bool, bool, bool, DirectiveSet*)+0x13ec

V  [libjvm.so+0x4f87da]  C2Compiler::compile_method(ciEnv*, ciMethod*, int,
bool, DirectiveSet*)+0xba

V  [libjvm.so+0x5c0c8d]
CompileBroker::invoke_compiler_on_method(CompileTask*)+0xf8d

V  [libjvm.so+0x5c15d8]  CompileBroker::compiler_thread_loop()+0x588

V  [libjvm.so+0xde6bb8]  JavaThread::thread_main_inner()+0x158

V  [libjvm.so+0xde6cf9]  JavaThread::run()+0x129

V  [libjvm.so+0xde9bce]  Thread::call_run()+0x7e

V  [libjvm.so+0xb337b1]  thread_native_entry(Thread*)+0xe1

On Thu, Oct 13, 2022 at 12:00 PM Wei  wrote:

> We also observed the same SIGSEGV crash during our test with Solr 9.0.0.
> It happens very rarely though,  seem 2 occurences during one month of
> testing.  We use Zulu JDK 17.34.
>
>
>-
>
>A fatal error has been detected by the Java Runtime Environment:
>SIGSEGV (0xb) at pc=0x7f96b852d3a1, pid=16597, tid=16637
># JRE version: OpenJDK Runtime Environment Zulu17.34+20-SA (17.0.3+7)
>(build 17.0.3+7-LTS)
># Java VM: OpenJDK 64-Bit Server VM Zulu17.34+20-SA (17.0.3+7-LTS,
>mixed mode, sharing, tiered, compressed class ptrs, g1 gc, linux-amd64)
># Problematic frame:
># V  [libjvm.so+0x9e13a1]
>PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x111
>
>
> Do we know which lucene/solr component would trigger this error?
>
> Regards,
> Wei
>
> On Thu, Oct 13, 2022 at 10:51 AM solr  wrote:
>
>> Hi.
>>
>> We tried to upgrade a number of solar images from 8.11 to 9.0.0 this week
>> and ran into the same problems with the official docker image as well
>> (approximately 30 running pods in Kubernetes, crashing on average once an
>> hour).
>>
>> We even tried to build a docker image with another base image
>> (bellsoft/liberica-openjdk-debian:17), with the same result (even though
>> the actual error differed somewhat (optimize instead of
>> build_loop_late_post_work)).
>>
>> For now we ended up with building a docker image of solr 9.0.0 based on
>> openjdk:11-jre and it has been running several hours without crashes.
>> Maybe the official docker image should be reverted to this until the bug is
>> fixed?
>>
>>
>> For reference: here are 2 crashes (hs_err_pidXX.log and replay_pidXX.log
>> can be provided on request):
>>
>>
>> Temurin-17.0.4.1+1:
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x7fd81c7e6153, pid=14, tid=85
>> #
>> # JRE version: OpenJDK Runtime Environment Temurin-17.0.4.1+1
>> (17.0.4.1+1) (build 17.0.4.1+1)
>> # Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.4.1+1 (17.0.4.1+1, mixed
>> mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc,
>> linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0xacc153]
>> PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x153
>> #
>> # Core dump will be written. Default location: /core.%e.14.%t
>> #
>> # An error report file with more information is saved as:
>> # /opt/solr-9.0.0/server/hs_err_pid14.log
>> {#
>> # Compiler replay data is saved as:
>> # /opt/solr-9.0.0/server/replay_pid14.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://github.com/adoptium/adoptium-support/issues
>> #
>> /opt/scripts/startSolr.sh: line 54:14 Aborted
>>  /opt/solr/bin/solr -f -p ${solrport} -m ${memory}
>> -Dsolr.jetty.request.header.size=65535 -Dsolr.disable.allowUrls=true
>> -Dsolrindex=${profile} -Dlog4j2.formatMsgNoLookups=true
>> -Dfinnapp=${finnapp} -Dsolr.master.host=${masterhost} -Denable.slave=true
>> -Denable.replication=true -Dsolr.http1=true
>> -Dsolr.disable.shardsWhitelist=true -Dodin.job.host=solr-cl-job
>> -Dodin.bap.host=solr-cl-bap -Dodin.motor.host=solr-cl-motor
>> -Dodin.estate.host=solr-cl-estate
>>
>>
>> bellsoft/liberica-openjdk-debian:17
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIG

Re: solr 9 standalone crashed after few hours - PhaseIdealLoop::build_loop_late_post_work

2022-10-13 Thread Jen-Ya Ku

It happened at the same CompileTrask on our land (OpenJDK17):

Thanks,
Jen-Ya
---  T H R E A D  ---

Current thread (0x7ff2f4a44630):  JavaThread "C2 CompilerThread0"
daemon [_thread_in_native, id=14826,
stack(0x7ff2d0429000,0x7ff2d052a000)]


Current CompileTask:
C2:80302242 17311   !   4
com.github.benmanes.caffeine.cache.BoundedLocalCache::put (731 bytes)

Stack: [0x7ff2d0429000,0x7ff2d052a000],  sp=0x7ff2d0524d70,
 free space=1007k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V  [libjvm.so+0xad1332]  PhaseIdealLoop::build_loop_late_post_work(Node*,
bool)+0xf2
V  [libjvm.so+0xad1d80]  PhaseIdealLoop::build_loop_late(VectorSet&,
Node_List&, Node_Stack&)+0x180
V  [libjvm.so+0xad26de]  PhaseIdealLoop::build_and_optimize()+0x78e
V  [libjvm.so+0x5d06c1]  PhaseIdealLoop::optimize(PhaseIterGVN&,
LoopOptsMode)+0x171
V  [libjvm.so+0x5ce5b5]  Compile::Optimize()+0xd85
V  [libjvm.so+0x5cff09]  Compile::Compile(ciEnv*, ciMethod*, int, bool,
bool, bool, bool, bool, DirectiveSet*)+0xe49
V  [libjvm.so+0x50f7d7]  C2Compiler::compile_method(ciEnv*, ciMethod*, int,
bool, DirectiveSet*)+0xf7
V  [libjvm.so+0x5d8f59]
 CompileBroker::invoke_compiler_on_method(CompileTask*)+0xf69
V  [libjvm.so+0x5d9c00]  CompileBroker::compiler_thread_loop()+0x4f0
V  [libjvm.so+0xe607b2]  JavaThread::thread_main_inner()+0x182
V  [libjvm.so+0xe63f7e]  Thread::call_run()+0xde
V  [libjvm.so+0xc1b361]  thread_native_entry(Thread*)+0xe1

On Thu, Oct 13, 2022 at 12:28 PM Wei  wrote:

> Looks our case is triggered from caffeine cache, different from
> https://bugs.openjdk.org/browse/JDK-8285835 where it happens in facet
> module.
>
>
> ---  T H R E A D  ---
>
>
> Current thread (0x7f96b1286f40):  JavaThread "C2 CompilerThread0"
> daemon [_thread_in_native, id=16637,
> stack(0x7f85f50ab000,0x7f85f51ac000)]
>
>
>
> Current CompileTask:
>
> C2:148683516 28882   !   4
> com.github.benmanes.caffeine.cache.BoundedLocalCache::put
> (731 bytes)
>
>
> Stack: [0x7f85f50ab000,0x7f85f51ac000],  sp=0x7f85f51a6e40,
> free
> space=1007k
>
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
>
> V  [libjvm.so+0x9e13a1]  PhaseIdealLoop::build_loop_late_post_work(Node*,
> bool)+0x111
>
> V  [libjvm.so+0x9e1910]  PhaseIdealLoop::build_loop_late(VectorSet&,
> Node_List&, Node_Stack&)+0x180
>
> V  [libjvm.so+0x9e2321]
> PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x841
>
> V  [libjvm.so+0x5b90da]  PhaseIdealLoop::optimize(PhaseIterGVN&,
> LoopOptsMode)+0x17a
>
> V  [libjvm.so+0x5b6b5e]  Compile::Optimize()+0x84e
>
> V  [libjvm.so+0x5b883c]  Compile::Compile(ciEnv*, ciMethod*, int, bool,
> bool, bool, bool, bool, DirectiveSet*)+0x13ec
>
> V  [libjvm.so+0x4f87da]  C2Compiler::compile_method(ciEnv*, ciMethod*, int,
> bool, DirectiveSet*)+0xba
>
> V  [libjvm.so+0x5c0c8d]
> CompileBroker::invoke_compiler_on_method(CompileTask*)+0xf8d
>
> V  [libjvm.so+0x5c15d8]  CompileBroker::compiler_thread_loop()+0x588
>
> V  [libjvm.so+0xde6bb8]  JavaThread::thread_main_inner()+0x158
>
> V  [libjvm.so+0xde6cf9]  JavaThread::run()+0x129
>
> V  [libjvm.so+0xde9bce]  Thread::call_run()+0x7e
>
> V  [libjvm.so+0xb337b1]  thread_native_entry(Thread*)+0xe1
>
> On Thu, Oct 13, 2022 at 12:00 PM Wei  wrote:
>
> > We also observed the same SIGSEGV crash during our test with Solr 9.0.0.
> > It happens very rarely though,  seem 2 occurences during one month of
> > testing.  We use Zulu JDK 17.34.
> >
> >
> >-
> >
> >A fatal error has been detected by the Java Runtime Environment:
> >SIGSEGV (0xb) at pc=0x7f96b852d3a1, pid=16597, tid=16637
> ># JRE version: OpenJDK Runtime Environment Zulu17.34+20-SA (17.0.3+7)
> >(build 17.0.3+7-LTS)
> ># Java VM: OpenJDK 64-Bit Server VM Zulu17.34+20-SA (17.0.3+7-LTS,
> >mixed mode, sharing, tiered, compressed class ptrs, g1 gc,
> linux-amd64)
> ># Problematic frame:
> ># V  [libjvm.so+0x9e13a1]
> >PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x111
> >
> >
> > Do we know which lucene/solr component would trigger this error?
> >
> > Regards,
> > Wei
> >
> > On Thu, Oct 13, 2022 at 10:51 AM solr  wrote:
> >
> >> Hi.
> >>
> >> We tried to upgrade a number of solar images from 8.11 to 9.0.0 this
> week
> >> and ran into the same problems with the official docker image as well
> >> (approximately 30 running pods in Kubernetes, crashing on average once
> an
> >> hour).
> >>
> >> We even tried to build a docker image with another base image
> >> (bellsoft/liberica-openjdk-debian:17), with the same result (even though
> >> the actual error differed somewhat (optimize instead of
> >> build_loop_late_post_work)).
> >>
> >> For now we ended up with building a docker image of solr 9.0.0 based on
> >> openjdk:11-jre and it has been running several hours without crashes.
> >> Maybe the official docker image should be reverted to this until the
> bug is
> >> fixed

Array formatted payload

2022-10-13 Thread Matthew Castrigno

The implicit handlers
/update

and
/update/json/docs

treat the same payload differently

/update requires the payload in [ ] where as /update/json/docs does not.

{field_1:data, field_2:data} throws the error "unknown command 'field_1'..."

but the same payload to /update/json/docs works fine.

I have my own requestHandler that uses solr.UpdateRequestHandler

How can my handler to accept the payload without [ ] around the json?

I am using the script update processor but the error is thrown before I can 
process the payload.

Thank you so much for any insight!

--
"This message is intended for the use of the person or entity to which it is 
addressed and may contain information that is confidential or privileged, the 
disclosure of which is governed by applicable law. If the reader of this 
message is not the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this information is strictly 
prohibited. If you have received this message by error, please notify us 
immediately and destroy the related message."

Re: Array formatted payload

2022-10-13 Thread dmitri maziuk


On 2022-10-13 3:02 PM, Matthew Castrigno wrote:

The implicit handlers
/update
and
/update/json/docs
treat the same payload differently


This is in The Fine Manual: the latter expects a *single* json doc 
(exactly why they called it "docs" plural is a mystery), the former can 
take a list of docs in [], a sequence of update commands in {}, or a 
single doc *with "json.command=false" request parameter*.


Dima

Re: Script Update Processor

2022-10-13 Thread Eric Pugh

Humm..  This doesn’t sound intentional at all…   Do you have a reproducible 
test case you can share?  

> On Oct 13, 2022, at 2:31 PM, dmitri maziuk  wrote:
> 
> On 2022-10-13 12:35 PM, Matthew Castrigno wrote:
>> Actually, it is the raw payload but has inserted  at what appears to 
>> be after every ","
>> Strange I suppose I can strip those without harm.
> 
> If you look at logging page in Solr admin interface, it'll have them (at 
> least in our 6.5.0 and 8.7.0) after every comma as well.
> 
> It's a "zero-width space", it has very limited uses and I can't think of any 
> rational reason to put one after a comma. I.e. it's got to be a bug.
> 
> Dima
> 

___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

Re: Array formatted payload

2022-10-13 Thread Matthew Castrigno

Thank you dmitri, I will try this when I get SOLR running properly again.

From: dmitri maziuk 
Sent: Thursday, October 13, 2022 3:02 PM
To: users@solr.apache.org 
Subject: Re: Array formatted payload

On 2022-10-13 3: 02 PM, Matthew Castrigno wrote: > The implicit handlers > 
/update > and > /update/json/docs > treat the same payload differently This is 
in The Fine Manual: the latter expects a *single* json doc (exactly why
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the St. Luke's email system.

ZjQcmQRYFpfptBannerEnd

On 2022-10-13 3:02 PM, Matthew Castrigno wrote:
> The implicit handlers
> /update
> and
> /update/json/docs
> treat the same payload differently

This is in The Fine Manual: the latter expects a *single* json doc
(exactly why they called it "docs" plural is a mystery), the former can
take a list of docs in [], a sequence of update commands in {}, or a
single doc *with "json.command=false" request parameter*.

Dima

--
"This message is intended for the use of the person or entity to which it is 
addressed and may contain information that is confidential or privileged, the 
disclosure of which is governed by applicable law. If the reader of this 
message is not the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this information is strictly 
prohibited. If you have received this message by error, please notify us 
immediately and destroy the related message."

Re: Script Update Processor

2022-10-13 Thread dmitri maziuk


On 2022-10-13 4:44 PM, Eric Pugh wrote:

Humm..  This doesn’t sound intentional at all…   Do you have a reproducible 
test case you can share?


I see them all the time on Logging page, I can attach a screenshot but 
it'll likely get striped of by the list software. Happens with Chrome, 
Edge, or Firefox. The OS is winders on both client and servers.


Dima

RE: IllegalArgumentException: Unknown directory

2022-10-13 Thread Oakley, Craig (NIH/NLM/NCBI) [C]

This error has happened again. Does anyone yet have any explanation or 
suggestion?

-Original Message-
From: Oakley, Craig (NIH/NLM/NCBI) [C]  
Sent: Friday, August 05, 2022 10:47 PM
To: users@solr.apache.org
Subject: RE: IllegalArgumentException: Unknown directory

This error has happened again. Does anyone yet have any explanation or 
suggestion?

-Original Message-
From: Oakley, Craig (NIH/NLM/NCBI) [C] 
Sent: Monday, May 02, 2022 2:29 PM
To: users@solr.apache.org
Subject: Re: IllegalArgumentException: Unknown directory

This has happened several more times, and I have notice something else which 
might be a clue:

The problem happened over the weekend; and the first erroneous complaint about 
/data/solr/subportal1/run_sel_cache_shard1_replica_n3/data/snapshot_metadata 
(as though it did not exist) occurred 17 minutes after 
/data/solr/subportal1/run_sel_cache_shard1_replica_n3/data/replication.properties
 was updated. Last month, the problem occurred just 40 seconds after 
replication.properties was updated.

What known connections might there be between replication.properties and 
snapshot_metadata?

-Original Message-
From: matthew sporleder  
Sent: Monday, March 28, 2022 9:41 AM
To: users@solr.apache.org
Subject: Re: [EXTERNAL] Re: IllegalArgumentException: Unknown directory

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and are confident the 
content is safe.


My only other guess (and I mean wild guess) is that because the error is
for a *lock* that it is actually a timeout or similar locking error with a
bad error message.

On Fri, Mar 25, 2022 at 11:11 AM Oakley, Craig (NIH/NLM/NCBI) [C]
 wrote:

> Thanks for the quick reply
>
> grep -i -c OutOfMemory solr.log.20220* shows zero
>
> Nothing new in /var/log/dmesg since reboot of the host a couple weeks ago
>
> Let me know if you have any other suggestions
>
> Thanks again
>
> -Original Message-
> From: matthew sporleder 
> Sent: Friday, March 25, 2022 11:00 AM
> To: users@solr.apache.org
> Subject: [EXTERNAL] Re: IllegalArgumentException: Unknown directory
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and are
> confident the content is safe.
>
>
> Is there an OOM anywhere in that log?  I've definitely seen java lose track
> of things during a slow-moving oom.
>
> Also definitely check dmesg for anything in that same timeframe if you
> still have the logs.
>
> On Fri, Mar 25, 2022 at 10:58 AM Oakley, Craig (NIH/NLM/NCBI) [C]
>  wrote:
>
> > I have a core which ceased responding either to select or to admin/core:
> > restarting the Solr instance resolved the problem, but I am wondering
> > whether there is some configuration which may need to be tweaked. Below
> is
> > a portion of solr.log from the time when the problem began. Please note
> > that the directory
> >
> /data/solr/subportal1/run_sel_cache_shard1_replica_n3/data/snapshot_metadata
> > does indeed exist
> >
> > 2022-03-25 08:47:58.526 INFO  (qtp1847637306-38437) [c:run_sel_index
> > s:shard1 r:core_node4 x:run_sel_index_shard1_replica_n3]
> o.a.s.c.S.Request
> > [run_sel_index_shard1_replica_n3]  webapp=/solr path=/select
> >
> params={q={!join+from%3Dacc_ref+to%3Dacc_s+fromIndex%3Drun_sel_cache}list_guid:6ccb6d6731f557a9fd3edb34ad637add&facet.limit=2&facet.field=datastore_provider_ss&facet.field=datastore_region_ss&facet.field=datastore_filetype_ss&facet.field=acc_s&facet.field=sra_study_s&facet.field=experiment_s&facet.field=bioproject_s&facet.field=biosample_s&facet.field=sample_acc_s&facet.field=sra_sample_s&facet.field=consent_s&facet.field=gap_accession_sam_ss&facet.field=libraryselection_s&facet.field=librarysource_s&facet.field=librarylayout_s&facet.field=platform_s&facet.field=submission_id_s&facet.field=assemblyname_s&facet.field=submission_id_run_s&facet.field=instrument_s&facet.field=bytes_l&facet.field=bases_l&facet.field=mbytes_l&facet.field=mbases_l&start=0&facet.mincount=1&rows=0&wt=json&facet=on}
> > hits=94 status=0 QTime=2610
> > 2022-03-25 08:47:58.526 INFO  (qtp1847637306-38437) [c:run_sel_index
> > s:shard1 r:core_node4 x:run_sel_index_shard1_replica_n3] o.a.s.c.SolrCore
> > [run_sel_cache_shard1_replica_n3]  CLOSING SolrCore
> > org.apache.solr.core.SolrCore@59c22833 > org.apache.solr.core.SolrCore@59c22833>
> > 2022-03-25 08:47:58.527 INFO  (qtp1847637306-38437) [c:run_sel_index
> > s:shard1 r:core_node4 x:run_sel_index_shard1_replica_n3]
> > o.a.s.m.SolrMetricManager Closing metric reporters for
> > registry=solr.core.run_sel_cache.shard1.replica_n3, tag=SolrCore@59c22833
> > 2022-03-25 08:47:58.531 INFO  (qtp1847637306-38437) [c:run_sel_index
> > s:shard1 r:core_node4 x:run_sel_index_shard1_replica_n3]
> > o.a.s.m.r.SolrJmxReporter Closing reporter
> > [org.apache.solr.metrics.reporters.SolrJmxReporter@2b7f5d5e: rootName =
> > null, domain = solr

Re: Solr SSL Troublshooting

2022-10-13 Thread Neal Tucker

If solr is speaking TLS on its listening port, could the problem simply be
that you have to tell curl that by adding an explicit “https://“ on the
beginning of your localhost url?


On Thu, Oct 13, 2022 at 10:58 AM Rayner, June  wrote:

> Hi Anshum
>
> Thanks for your response. Yes, we're running Solr standalone
>
> We start Solr as a service.   The startup script uses the following to
> start solr
> "/usr/local/vufind-5.0/solr/vendor/bin/solr" "$1" -force -p 8080 -s
> /usr/local/vufind-5.0/solr/vufind -m 4096M -a "-Ddisable.configEdit=true
> -Dsolr.log=/usr/local/vufind-5.0/solr/vufind/logs/jetty
>
> Regards,
>
> June
>
> -Original Message-
> From: Anshum Gupta 
> Sent: Thursday, October 13, 2022 12:50 PM
> To: users@solr.apache.org
> Subject: Re: Solr SSL Troublshooting
>
> How are you starting Solr? Seems like you're running it in standalone
> mode, can you please confirm?
>
> On Thu, Oct 13, 2022 at 9:44 AM Rayner, June 
> wrote:
>
> > Hi Jan
> >
> > Thanks for your response. With the SSL configured,
> >
> > we get an ERR_INVALID_HTTP_RESPONSE error when we access the solr
> > admin URL in a browser
> >
> > with cURL, we get the following
> > curl localhost:8080/solr/#/dogs/query
> > curl: (1) Received HTTP/0.9 when not allowed
> >
> > There are 2 lines in the solr log that mention the Solr port cat
> > solr.log | grep 8080
> > 2022-10-13 16:32:56.616 INFO  (main) [   ] o.a.s.s.SolrDispatchFilter /
> > __| ___| |_ _   Starting in standalone mode on port 8080
> > 2022-10-13 16:32:58.339 INFO  (main) [   ] o.e.j.s.AbstractConnector
> > Started ServerConnector@18245eb0{SSL, (ssl, alpn, h2, http/1.1)}{
> > 0.0.0.0:8080}
> >
> > These are the last lines in the log itself
> > 2022-10-13 16:32:59.268 INFO
> > (searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio]
> > o.a.s.c.QuerySenderListener QuerySenderListener done.
> > 2022-10-13 16:32:59.268 INFO
> > (searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio]
> > o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker:
> > default
> > 2022-10-13 16:32:59.269 INFO
> > (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> > o.a.s.c.S.Request [biblio2]  webapp=null path=null
> > params={q=science+art+business+engineering+history&facet.field=format&
> > distrib=false&fq=format:book&event=firstSearcher}
> > hits=0 status=0 QTime=98
> > 2022-10-13 16:32:59.269 INFO
> > (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> > o.a.s.c.QuerySenderListener QuerySenderListener done.
> > 2022-10-13 16:32:59.271 INFO
> > (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> > o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker:
> > default
> > 2022-10-13 16:32:59.301 INFO
> > (searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio]
> > o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker:
> > basicSpell
> > 2022-10-13 16:32:59.304 INFO
> > (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> > o.a.s.h.c.SpellCheckComponent Loading spell index for spellchecker:
> > basicSpell
> > 2022-10-13 16:32:59.324 INFO
> > (searcherExecutor-17-thread-1-processing-x:biblio) [   x:biblio]
> > o.a.s.c.SolrCore [biblio]  Registered new searcher autowarm time: 0 ms
> > 2022-10-13 16:32:59.328 INFO
> > (searcherExecutor-16-thread-1-processing-x:biblio2) [   x:biblio2]
> > o.a.s.c.SolrCore [biblio2]  Registered new searcher autowarm time: 0
> > ms
> >
> > Regards,
> >
> > June
> >
> >
> > -Original Message-
> > From: Jan Høydahl 
> > Sent: Thursday, October 13, 2022 11:36 AM
> > To: users@solr.apache.org
> > Subject: Re: Solr SSL Troublshooting
> >
> > >  but we can't access the Solr Admin page.
> >
> >
> > What exactly does this mean?
> > Do you see the last line Jetty prints out in the log that it is
> > listening to port 8983?
> > What happens when you try to connect to the port, with e.g. cURL?
> >
> > Jan
> >
> > The information contained in this e-mail, and any attachment, is
> > confidential and is intended solely for the use of the intended
> recipient.
> > Access, copying or re-use of the e-mail or any attachment, or any
> > information contained therein, by any other person is not authorized.
> > If you are not the intended recipient please return the e-mail to the
> > sender and delete it from your computer. Although we attempt to sweep
> > e-mail and attachments for viruses, we do not guarantee that either
> > are virus-free and accept no liability for any damage sustained as a
> result of viruses.
> >
>
>
> --
> Anshum Gupta
> The information contained in this e-mail, and any attachment, is
> confidential and is intended solely for the use of the intended recipient.
> Access, copying or re-use of the e-mail or any attachment, or any
> information contained therein, by any other person is not authorized. If
> you are not the intended recipient please return the e-mail to the sender
> and delete it

HTTP ERROR 500 java.lang.NoClassDefFoundError: Lorg/apache/lucene/index/Term

2022-10-13 Thread Matthew Castrigno

I am running SOLR on my windows machine and it gets in this state where every 
update has this response. Even when I roll back to previously working branches, 
I still get this error. Sometimes restarting works, sometimes it just "fixes 
itself".  Not sure why it would suddenly not be able to get declared fields.

As always, any insight is greatly appreciated.
[cid:04f7401d-6b8d-4b08-a97b-b96df73dd06d]
HTTP ERROR 500 java.lang.NoClassDefFoundError: Lorg/apache/lucene/index/Term;
URI:/solr/talix/index
STATUS: 500
MESSAGE:java.lang.NoClassDefFoundError: Lorg/apache/lucene/index/Term;
SERVLET:default
CAUSED BY:  java.lang.NoClassDefFoundError: Lorg/apache/lucene/index/Term;
CAUSED BY:  java.lang.ClassNotFoundException: org.apache.lucene.index.Term
Caused by:

java.lang.NoClassDefFoundError: Lorg/apache/lucene/index/Term;
at java.base/java.lang.Class.getDeclaredFields0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredFields(Class.java:3061)
at java.base/java.lang.Class.privateGetPublicFields(Class.java:3088)
at java.base/java.lang.Class.getFields(Class.java:1814)
at 
jdk.dynalink/jdk.dynalink.beans.FacetIntrospector.getFields(FacetIntrospector.java:112)
at 
jdk.dynalink/jdk.dynalink.beans.AbstractJavaLinker.(AbstractJavaLinker.java:138)
at jdk.dynalink/jdk.dynalink.beans.BeanLinker.(BeanLinker.java:92)
at 
jdk.dynalink/jdk.dynalink.beans.BeansLinker$1.computeValue(BeansLinker.java:144)
at 
jdk.dynalink/jdk.dynalink.beans.BeansLinker$1.computeValue(BeansLinker.java:136)
at java.base/java.lang.ClassValue.getFromHashMap(ClassValue.java:228)
at java.base/java.lang.ClassValue.getFromBackup(ClassValue.java:210)
at java.base/java.lang.ClassValue.get(ClassValue.java:116)
at 
jdk.dynalink/jdk.dynalink.beans.BeansLinker.getStaticLinkerForClass(BeansLinker.java:210)
at 
jdk.dynalink/jdk.dynalink.beans.BeansLinker.getLinkerForClass(BeansLinker.java:180)
at 
jdk.dynalink/jdk.dynalink.beans.BeansLinker.getGuardedInvocation(BeansLinker.java:333)
at 
jdk.scripting.nashorn/jdk.nashorn.internal.runtime.linker.NashornBeansLinker.getGuardedInvocation(NashornBeansLinker.java:169)
at 
jdk.scripting.nashorn/jdk.nashorn.internal.runtime.linker.NashornBeansLinker.getGuardedInvocation(NashornBeansLinker.java:156)
at 
jdk.dynalink/jdk.dynalink.linker.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:109)
at 
jdk.dynalink/jdk.dynalink.LinkerServicesImpl.lambda$getGuardedInvocation$0(LinkerServicesImpl.java:137)
at 
jdk.dynalink/jdk.dynalink.LinkerServicesImpl.getWithLookupInternal(LinkerServicesImpl.java:168)
at 
jdk.dynalink/jdk.dynalink.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:135)
at 
jdk.dynalink/jdk.dynalink.DynamicLinker.relink(DynamicLinker.java:242)
at 
jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$14$333A$\^eval\_.processAdd(:12)
at 
jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:657)
at 
jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
at 
jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
at 
jdk.scripting.nashorn/jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:202)
at 
jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:393)
at 
jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:197)
at 
org.apache.solr.scripting.update.ScriptUpdateProcessorFactory$ScriptUpdateProcessor.invokeFunctionUnsafe(ScriptUpdateProcessorFactory.java:446)
at 
org.apache.solr.scripting.update.ScriptUpdateProcessorFactory$ScriptUpdateProcessor$1.run(ScriptUpdateProcessorFactory.java:436)
at 
org.apache.solr.scripting.update.ScriptUpdateProcessorFactory$ScriptUpdateProcessor$1.run(ScriptUpdateProcessorFactory.java:433)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.solr.scripting.update.ScriptUpdateProcessorFactory$ScriptUpdateProcessor.invokeFunction(ScriptUpdateProcessorFactory.java:432)
at 
org.apache.solr.scripting.update.ScriptUpdateProcessorFactory$ScriptUpdateProcessor.processAdd(ScriptUpdateProcessorFactory.java:386)
at 
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleAdds(JsonLoader.java:552)
at 
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:183)
at 
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:158)
at org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.j

Re: HTTP ERROR 500 java.lang.NoClassDefFoundError: Lorg/apache/lucene/index/Term

2022-10-13 Thread Jan Høydahl

Please provide more information on your environment

- Solr version and Java version
- How you installed Solr in Windows
- How you start Solr
- Copy of Solr's log file (solr.log)
- Info on any modifications / custom plugins etc you run

Java simply cannot find the class which is uncommon for core classes like this.

Jan

> 14. okt. 2022 kl. 00:36 skrev Matthew Castrigno :
> 
> I am running SOLR on my windows machine and it gets in this state where every 
> update has this response. Even when I roll back to previously working 
> branches, I still get this error. Sometimes restarting works, sometimes it 
> just "fixes itself".  Not sure why it would suddenly not be able to get 
> declared fields. 
> 
> As always, any insight is greatly appreciated.
> 
> HTTP ERROR 500 java.lang.NoClassDefFoundError: Lorg/apache/lucene/index/Term;
> 
> URI:  /solr/talix/index
> STATUS:   500
> MESSAGE:  java.lang.NoClassDefFoundError: Lorg/apache/lucene/index/Term;
> SERVLET:  default
> CAUSED BY:java.lang.NoClassDefFoundError: Lorg/apache/lucene/index/Term;
> CAUSED BY:java.lang.ClassNotFoundException: org.apache.lucene.index.Term
> Caused by:
> 
> java.lang.NoClassDefFoundError: Lorg/apache/lucene/index/Term;
>   at java.base/java.lang.Class.getDeclaredFields0(Native Method)
>   at java.base/java.lang.Class.privateGetDeclaredFields(Class.java:3061)
>   at java.base/java.lang.Class.privateGetPublicFields(Class.java:3088)
>   at java.base/java.lang.Class.getFields(Class.java:1814)
>   at 
> jdk.dynalink/jdk.dynalink.beans.FacetIntrospector.getFields(FacetIntrospector.java:112)
>   at 
> jdk.dynalink/jdk.dynalink.beans.AbstractJavaLinker.(AbstractJavaLinker.java:138)
>   at jdk.dynalink/jdk.dynalink.beans.BeanLinker.(BeanLinker.java:92)
>   at 
> jdk.dynalink/jdk.dynalink.beans.BeansLinker$1.computeValue(BeansLinker.java:144)
>   at 
> jdk.dynalink/jdk.dynalink.beans.BeansLinker$1.computeValue(BeansLinker.java:136)
>   at java.base/java.lang.ClassValue.getFromHashMap(ClassValue.java:228)
>   at java.base/java.lang.ClassValue.getFromBackup(ClassValue.java:210)
>   at java.base/java.lang.ClassValue.get(ClassValue.java:116)
>   at 
> jdk.dynalink/jdk.dynalink.beans.BeansLinker.getStaticLinkerForClass(BeansLinker.java:210)
>   at 
> jdk.dynalink/jdk.dynalink.beans.BeansLinker.getLinkerForClass(BeansLinker.java:180)
>   at 
> jdk.dynalink/jdk.dynalink.beans.BeansLinker.getGuardedInvocation(BeansLinker.java:333)
>   at 
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.linker.NashornBeansLinker.getGuardedInvocation(NashornBeansLinker.java:169)
>   at 
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.linker.NashornBeansLinker.getGuardedInvocation(NashornBeansLinker.java:156)
>   at 
> jdk.dynalink/jdk.dynalink.linker.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:109)
>   at 
> jdk.dynalink/jdk.dynalink.LinkerServicesImpl.lambda$getGuardedInvocation$0(LinkerServicesImpl.java:137)
>   at 
> jdk.dynalink/jdk.dynalink.LinkerServicesImpl.getWithLookupInternal(LinkerServicesImpl.java:168)
>   at 
> jdk.dynalink/jdk.dynalink.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:135)
>   at 
> jdk.dynalink/jdk.dynalink.DynamicLinker.relink(DynamicLinker.java:242)
>   at 
> jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$14$333A$\^eval\_.processAdd(:12)
>   at 
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:657)
>   at 
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
>   at 
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
>   at 
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:202)
>   at 
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:393)
>   at 
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:197)
>   at 
> org.apache.solr.scripting.update.ScriptUpdateProcessorFactory$ScriptUpdateProcessor.invokeFunctionUnsafe(ScriptUpdateProcessorFactory.java:446)
>   at 
> org.apache.solr.scripting.update.ScriptUpdateProcessorFactory$ScriptUpdateProcessor$1.run(ScriptUpdateProcessorFactory.java:436)
>   at 
> org.apache.solr.scripting.update.ScriptUpdateProcessorFactory$ScriptUpdateProcessor$1.run(ScriptUpdateProcessorFactory.java:433)
>   at java.base/java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.solr.scripting.update.ScriptUpdateProcessorFactory$ScriptUpdateProcessor.invokeFunction(ScriptUpdateProcessorFactory.java:432)
>   at 
> org.apache.solr.scripting.update.ScriptUpdateProcessorFactory$ScriptUpdateProcessor.processAdd(ScriptUpdatePr

Re: Solr 9 and the Affinity placement plugin

Re: solr 9 standalone crashed after few hours - PhaseIdealLoop::build_loop_late_post_work

Solr SSL Troublshooting

Re: Solr SSL Troublshooting

RE: Solr SSL Troublshooting

Re: Solr SSL Troublshooting

Script Update Processor

Re: Script Update Processor

Re: solr 9 standalone crashed after few hours - PhaseIdealLoop::build_loop_late_post_work

RE: Solr SSL Troublshooting

Re: Script Update Processor

Re: Modifying maxFormContentSize in Apache Solr service.

Re: solr 9 standalone crashed after few hours - PhaseIdealLoop::build_loop_late_post_work

Re: solr 9 standalone crashed after few hours - PhaseIdealLoop::build_loop_late_post_work

Re: solr 9 standalone crashed after few hours - PhaseIdealLoop::build_loop_late_post_work

Array formatted payload

Re: Array formatted payload

Re: Script Update Processor

Re: Array formatted payload

Re: Script Update Processor

RE: IllegalArgumentException: Unknown directory

Re: Solr SSL Troublshooting

HTTP ERROR 500 java.lang.NoClassDefFoundError: Lorg/apache/lucene/index/Term

Re: HTTP ERROR 500 java.lang.NoClassDefFoundError: Lorg/apache/lucene/index/Term

24 matches

Site Navigation

Mail list logo

Footer information