Re: disabling schemaless mode - SolrCloud 8.11.2

[Vincenzo D'Amore]

Hi Shawn, Alex,

thanks for the update.
In the first instance I have disabled entirely the
updateRequestProcessorChain "add-unknown-fields-to-the-schema".
I can confirm that since then Solr continues to handle things correctly
under the hood.
I agree with you, configuration should be as explicit and transparent as
possible.
it seems that LogUpdateProcessorFactory and RunUpdateProcessorFactory are
still there, somehow.
I'm only afraid of what I'm losing by not having
DistributedUpdateProcessorFactory configured explicitly, is even this
component present by default?
Where the default processors are configured?

On Wed, Oct 12, 2022 at 7:55 PM Shawn Heisey  wrote:

> On 10/12/22 05:54, Vincenzo D'Amore wrote:
> > Does anyone know what's the responsibility of
> > DistributedUpdateProcessorFactory?
>
> That update processor takes care of atomic update functionality and
> farming out update requests to other Solr nodes, in particular for
> SolrCloud.  It probably has some other functionalities, but I haven't
> looked at its code recently.
>
> > Today I realized that in SolrCloud when disabling the schemaless mode, we
> > are going to disable also:
> >
> > - LogUpdateProcessorFactory,
> > - DistributedUpdateProcessorFactory,
> > - RunUpdateProcessorFactory
>
> The LogUpdate processor logs the request, usually that goes to
> solr.log.  The RunUpdate processor actually does the update.   I believe
> that if any of those 3 processors are removed from a definition, they
> are still automatically performed by Solr.  It is better to leave them
> in the definition so that anyone looking at it knows exactly what is
> being done and doesn't need to know about Solr's internal implicit
> handling.  If you are entirely removing all processor chains, then don't
> worry about it.  Solr will handle things correctly.
>
> > Those processors don't seem to be related to the schemaless mode, in
> > particular DistributedUpdateProcessorFactory.
>
> You are correct, they are not related to schemaless mode, but they are
> important.
>
> Thanks,
> Shawn
>
>

-- 
Vincenzo D'Amore

Re: disabling schemaless mode - SolrCloud 8.11.2

[Vincenzo D'Amore]

Hi Alex,

Also, when you disable schemaless, make sure you don't have implicit
> conversions happening that the chain also provides. E. G. Date as text gets
> converted to real date.


On second thought, thanks a lot, this is a very helpful suggestion, I
didn't realize immediately this side effect.
Disabling it can be dangerous.


-- 
Vincenzo D'Amore

Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined

[Nick Vladiceanu]

hello folks,
we’re in process of upgrading our Solr from 8.11 to 9.0. While upgrading the 
image for CI tests (meaning solr runs in standalone mode), we’ve spotted that 
Solr fails to create cores with a “NullPointerException" error when 
“shardHandlerFactory” is defined for any handlers in the solrconfig.xml file.

Snippet from solrconfig.xml:


${socketTimeout:800}
${connTimeout:500}



Snippet of NullPointerException (full text here: https://justpaste.it/5lntq 
 ):

olxeu-atlas-web-dist-solr-1  | Caused by: java.lang.NullPointerException
olxeu-atlas-web-dist-solr-1  |  at 
org.apache.solr.handler.component.HttpShardHandlerFactory.setSecurityBuilder(HttpShardHandlerFactory.java:299)
 ~[?:?]
olxeu-atlas-web-dist-solr-1  |  at 
org.apache.solr.handler.component.SearchHandler.inform(SearchHandler.java:185) 
~[?:?]
olxeu-atlas-web-dist-solr-1  |  at 
org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:722) 
~[?:?]
olxeu-atlas-web-dist-solr-1  |  at 
org.apache.solr.core.SolrCore.(SolrCore.java:1155) ~[?:?]
olxeu-atlas-web-dist-solr-1  |  at 
org.apache.solr.core.SolrCore.(SolrCore.java:1048) ~[?:?]
olxeu-atlas-web-dist-solr-1  |  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1560)
 ~[?:?]
olxeu-atlas-web-dist-solr-1  |  at 
org.apache.solr.core.CoreContainer.lambda$load$10(CoreContainer.java:950) ~[?:?]
olxeu-atlas-web-dist-solr-1  |  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202)
 ~[metrics-core-4.1.5.jar:4.1.5]

Steps:
1. Run library/solr:9.0.0 in docker (default config, no tunings); mount a 
volume with solrconfig.xml that contains shardHandlerFactory and schema.xml;
2. Create a core using the solrconfig.xml: 
http://localhost:8983/solr/admin/cores?action=CREATE&name=test&instanceDir=/var/solr/data/test&config=solrconfig.xml&dataDir=data/
 

3. Failure with nullPointerException;
4. Remove the shardHandlerFactory block;
5. Repeat step 2;
6. Success.

Works fine when running Solr in SolrCloud mode.

It’s understandable that shardHandlerFactory might not have any effect when 
running Solr in Standalone mode, since there is not inter-nodes requests 
routing, however, there are scenarios when we need to test and apply exactly 
the same solrconfig.xml in Standalone mode (i.e. during CI tests) and in Cloud 
mode (i.e. production clusters). What should be the expected behaviour, 
ignoring irrelevant configuration as it used to be in previous version of Solr?

Did anyone else face this issue? What would be the approach to solve it? 
Perhaps, there is a bug reported already? Thanks

Best regards,
Nick Vladiceanu

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

[Jan Høydahl]

Thanks for the insight Fredrik.

I created https://issues.apache.org/jira/browse/SOLR-16463 to track this. 
Suggestion is to publish an official convenience image for temurin11

Jan

> 13. okt. 2022 kl. 15:58 skrev 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: Script Update Processor

[Eric Pugh]

Would you mind creating a JIRA issue then?  You can add the screenshot there.   
I haven’t seen this issue, but maybe haven’t dug into it, so the more 
reproducible it is, the easier it is for me to look into it ;-).

I’d love to hear that the problem is reproducible on Solr 9, as that is where I 
would start from...

> On Oct 13, 2022, at 5:53 PM, dmitri maziuk  wrote:
> 
> 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
> 

___
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: Solr SSL Troublshooting

[Rayner, June]

Hi Neal

Brilliant - that works!I'm also able to get to the Solr admin screen in a 
browser if I add https:// to the beginning of the URL.

Regards

June

-Original Message-
From: Neal Tucker 
Sent: Thursday, October 13, 2022 6:11 PM
To: users@solr.apache.org
Subject: Re: Solr SSL Troublshooting

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=forma
> > t& 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 att

Re: Script Update Processor

[Matthew Castrigno]

This issue is easily reproduced in 9.0 using the example script and logging 
cmd.solrDoc in the processAdd function.

From: Eric Pugh 
Sent: Friday, October 14, 2022 5:57 AM
To: users@solr.apache.org 
Subject: Re: Script Update Processor

Would you mind creating a JIRA issue then? You can add the screenshot there. I 
haven’t seen this issue, but maybe haven’t dug into it, so the more 
reproducible it is, the easier it is for me to look into it ;-). I’d love to 
hear that the problem
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the St. Luke's email system.

ZjQcmQRYFpfptBannerEnd

Would you mind creating a JIRA issue then?  You can add the screenshot there.   
I haven’t seen this issue, but maybe haven’t dug into it, so the more 
reproducible it is, the easier it is for me to look into it ;-).

I’d love to hear that the problem is reproducible on Solr 9, as that is where I 
would start from...

> On Oct 13, 2022, at 5:53 PM, dmitri maziuk  wrote:
>
> 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
>

___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
https://urldefense.com/v3/__http://www.opensourceconnections.com__;!!FkC3_z_N!JCG0Z2_8cCt90aDFXAoKJQpUXBhc11xVTssrltw1G_ofQvargsfOCWtzjwEDH2RQMfVzuGqz1QR3ONbPqEm_qQ$
  
 | 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.


--
"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

[Dave]

No one should ever actually use a .0 version

> On Oct 14, 2022, at 8:41 AM, Matthew Castrigno  wrote:
> 
> This issue is easily reproduced in 9.0 using the example script and logging 
> cmd.solrDoc in the processAdd function.
> 
> From: Eric Pugh 
> Sent: Friday, October 14, 2022 5:57 AM
> To: users@solr.apache.org 
> Subject: Re: Script Update Processor
> 
> Would you mind creating a JIRA issue then? You can add the screenshot there. 
> I haven’t seen this issue, but maybe haven’t dug into it, so the more 
> reproducible it is, the easier it is for me to look into it ;-). I’d love to 
> hear that the problem
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
> This message came from outside the St. Luke's email system.
> 
> ZjQcmQRYFpfptBannerEnd
> 
> Would you mind creating a JIRA issue then?  You can add the screenshot there. 
>   I haven’t seen this issue, but maybe haven’t dug into it, so the more 
> reproducible it is, the easier it is for me to look into it ;-).
> 
> I’d love to hear that the problem is reproducible on Solr 9, as that is where 
> I would start from...
> 
>> On Oct 13, 2022, at 5:53 PM, dmitri maziuk  wrote:
>> 
>>> 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
>> 
> 
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> https://urldefense.com/v3/__http://www.opensourceconnections.com__;!!FkC3_z_N!JCG0Z2_8cCt90aDFXAoKJQpUXBhc11xVTssrltw1G_ofQvargsfOCWtzjwEDH2RQMfVzuGqz1QR3ONbPqEm_qQ$
>   
>   > | 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.
> 
> 
> --
> "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: Modifying maxFormContentSize in Apache Solr service.

[Kaushal Shriyan]

On Fri, Oct 14, 2022 at 12:19 AM Kaushal Shriyan 
wrote:

>
>
> 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
>

Hi,

I have configured the below settings in /opt/solr/server/etc/jetty.xml


https







client_loop: send disconnect: Broken
pipee="solr.jetty.header.cache.size" default="*5120*" />


Please comment if max content size in the request configured as above is
the right way to implement it. Thanks in advance.

Best Regards,

Kaushal