Re: 8.5 release

[Joel Bernstein]

Finished the backport for https://issues.apache.org/jira/browse/SOLR-14073.

Thanks!


Joel Bernstein
http://joelsolr.blogspot.com/


On Mon, Mar 9, 2020 at 8:44 AM Joel Bernstein  wrote:

> Ok, I'll do the backport today. Thanks!
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
>
> On Mon, Mar 9, 2020 at 6:21 AM Alan Woodward  wrote:
>
>> Thanks Uwe!
>>
>> On 7 Mar 2020, at 10:06, Uwe Schindler  wrote:
>>
>> Hi,
>>
>> FYI, I cleaned, renamed, and changed the Jenkins Jobs, so the 8.5 branch
>> is in the loop on ASF Jenkins and Policeman Jenkins.
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>> *From:* Alan Woodward 
>> *Sent:* Wednesday, March 4, 2020 5:35 PM
>> *To:* dev@lucene.apache.org
>> *Subject:* Re: 8.5 release
>>
>> I’ve created a branch for the 8.5 release (`branch_8_5`) and pushed it to
>> the apache repository.  We’re now at feature freeze, so only bug fixes
>> should be pushed to the branch.
>>
>> I can see from
>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20priority%20%3D%20Blocker%20AND%20fixVersion%20%3D%208.5%20ORDER%20BY%20priority%20DESC
>> 
>>  that
>> we have 4 tickets marked as Blockers for this release.  I plan to build a
>> first release candidate next Monday, which gives us a few days to resolve
>> these.  If that’s not going to be long enough, please let me know.
>>
>> Uwe, Steve, can one of you start the Jenkins tasks for the new branch?
>>
>> Thanks, Alan
>>
>>
>> On 3 Mar 2020, at 14:50, Alan Woodward  wrote:
>>
>> PSA: I’ve had to generate a new GPG key for this release, and it takes a
>> while for it to get mirrored to the lucene KEYS file.  I’ll hold off
>> cutting the branch until everything is ready, so it will probably now be
>> tomorrow UK time before I start the release proper.
>>
>>
>> On 25 Feb 2020, at 07:49, Noble Paul  wrote:
>>
>> +1
>>
>> On Wed, Feb 19, 2020 at 9:35 PM Ignacio Vera  wrote:
>>
>>
>> +1
>>
>> On Tue, Feb 18, 2020 at 7:26 PM Jan Høydahl 
>> wrote:
>>
>>
>> +1
>>
>> That should give us time to update release docs for the new website too.
>>
>> Jan Høydahl
>>
>> 18. feb. 2020 kl. 18:28 skrev Adrien Grand :
>>
>> 
>> +1
>>
>> On Tue, Feb 18, 2020 at 4:58 PM Alan Woodward 
>> wrote:
>>
>>
>> Hi all,
>>
>> It’s been a while since we released lucene-solr 8.4, and we’ve
>> accumulated quite a few nice new features since then.  I’d like to
>> volunteer to be a release manager for an 8.5 release.  If there's
>> agreement, then I plan to cut the release branch two weeks today, on
>> Tuesday 3rd March.
>>
>> - Alan
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
>>
>>
>>
>> --
>> Adrien
>>
>>
>>
>>
>> --
>> -
>> Noble Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
>>
>>
>>

Re: Support for field removal

[David Smiley]

See https://issues.apache.org/jira/browse/LUCENE-8551

The main thing missing is that the stored fields data doesn't actually
store what IDs are being used (!).  If that were in place, I could imagine
a CLI tool to purge the IDs.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Mon, Mar 9, 2020 at 2:53 PM Michael Kleen  wrote:

> Hello,
>
> i am interested in the implementation of the field removal from an index.
> I am a Lucene user and I have a basic understanding of the internals. I
> have a few first questions and I hope this is the right place to ask them.
>
> Is already someone working on this topic ?
>
> Are there some real blockers for this feature ?
>
> From my basic understanding, field removal should work conceptually in the
> following way: The FieldInfo which is supposed to be removed would need to
> be first stored until the segment merge is happening. Once the segment
> merge is happening the field has to excluded from the new segment. Is this
> correct, or do I miss something here ?
>
> Thank you for your time,
>
> Michael
>

Re: Support for field removal

[Erick Erickson]

There’s an SIP (Solr Improvement Proposal) that would encompass this. It takes 
a slightly different approach by forcibly rewriting _all_ segments without 
exceeding the size limitations of Tiered Merge Policy. I can’t quite get to it 
at this point.

We’ve worked out a mechanism for this that allowed docValues to be added to a 
field that was indexed, but haven’t worked on various other “safe” operations, 
field removal being one of them.

 
https://cwiki.apache.org/confluence/display/SOLR/SIP-2+Support+safe+index+transformations+without+reindexing

Best,
Erick

> On Mar 9, 2020, at 11:53, Michael Kleen  wrote:
> 
> 
> Hello, 
> 
> i am interested in the implementation of the field removal from an index. I 
> am a Lucene user and I have a basic understanding of the internals. I have a 
> few first questions and I hope this is the right place to ask them.
> 
> Is already someone working on this topic ?
> 
> Are there some real blockers for this feature ?
> 
> From my basic understanding, field removal should work conceptually in the 
> following way: The FieldInfo which is supposed to be removed would need to be 
> first stored until the segment merge is happening. Once the segment merge is 
> happening the field has to excluded from the new segment. Is this correct, or 
> do I miss something here ? 
> 
> Thank you for your time,
> 
> Michael

Support for field removal

[Michael Kleen]

Hello,

i am interested in the implementation of the field removal from an index. I
am a Lucene user and I have a basic understanding of the internals. I have
a few first questions and I hope this is the right place to ask them.

Is already someone working on this topic ?

Are there some real blockers for this feature ?

>From my basic understanding, field removal should work conceptually in the
following way: The FieldInfo which is supposed to be removed would need to
be first stored until the segment merge is happening. Once the segment
merge is happening the field has to excluded from the new segment. Is this
correct, or do I miss something here ?

Thank you for your time,

Michael

Re: SOLR version 8 bug???

[Jan Høydahl]

Please the solr-user mailing list for this. Once you get the bug confirmed you 
can open a jira issue.

Jan Høydahl

> 9. mar. 2020 kl. 16:10 skrev Staley, Phil R - DCF :
> 
> 
> We recently upgraded to our Drupal 8 sites to SOLR 8.3.1.  We are now getting 
> reports of certain patterns of search terms resulting in an error that reads, 
> “The website encountered an unexpected error. Please try again later.” 
> 
> Below is a list of example terms that always result in this error and a 
> similar list that works fine.  The problem pattern seems to be a search term 
> that contains 2 or 3 characters followed by a space, followed by additional 
> text. 
> 
> To confirm that the problem is version 8 of SOLR, I have updated our local 
> and UAT sites with the latest Drupal updates that did include an update to 
> the Search API Solr module and tested the terms below under SOLR 7.7.2, 
> 8.3.1, and 8.4.1.  Under version 7.7.2  everything works fine. Under either 
> of the version 8, the problem returns.
> 
> Thoughts?
> 
>  Search terms that result in error
> 
> • w-2 agency directory
> 
> • agency w-2 directory
> 
> • w-2 agency
> 
> • w-2 directory
> 
> • w2 agency directory
> 
> • w2 agency
> 
> • w2 directory
> 
>  Search terms that do not result in error
> 
> • w-22 agency directory
> 
> • agency directory w-2
> 
> • agency w-2directory
> 
> • agencyw-2 directory
> 
> • w-2
> 
> • w2
> 
> • agency directory
> 
> • agency • directory
> 
> • -2 agency directory
> 
> • 2 agency directory
> 
> • w-2agency directory
> 
> • w2agency directory
> 
>  

SOLR version 8 bug???

[Staley, Phil R - DCF]

We recently upgraded to our Drupal 8 sites to SOLR 8.3.1.  We are now getting 
reports of certain patterns of search terms resulting in an error that reads, 
"The website encountered an unexpected error. Please try again later."

Below is a list of example terms that always result in this error and a similar 
list that works fine.  The problem pattern seems to be a search term that 
contains 2 or 3 characters followed by a space, followed by additional text.

To confirm that the problem is version 8 of SOLR, I have updated our local and 
UAT sites with the latest Drupal updates that did include an update to the 
Search API Solr module and tested the terms below under SOLR 7.7.2, 8.3.1, and 
8.4.1.  Under version 7.7.2  everything works fine. Under either of the version 
8, the problem returns.

Thoughts?

 Search terms that result in error

* w-2 agency directory

* agency w-2 directory

* w-2 agency

* w-2 directory

* w2 agency directory

* w2 agency

* w2 directory

 Search terms that do not result in error

* w-22 agency directory

* agency directory w-2

* agency w-2directory

* agencyw-2 directory

* w-2

* w2

* agency directory

* agency * directory

* -2 agency directory

* 2 agency directory

* w-2agency directory

* w2agency directory

Re: Upgrading Zookeeper?

[Kevin Risden]

Go with 3.5.7 since I am pretty sure we have some curator usage. I just
looked at upgrading Apache Knox to Zookeeper 3.6.0 [1] and there are some
curator/zk issues when testing. There is a curator ticket to update [2].

PS - Looks like there is a ticket for this already [3] going to comment
there too.

[1] https://issues.apache.org/jira/browse/KNOX-2283
[2] https://issues.apache.org/jira/browse/CURATOR-558
[3] https://issues.apache.org/jira/browse/SOLR-14312

Kevin Risden


On Sun, Mar 8, 2020 at 5:36 PM Jörn Franke  wrote:

> Is the Kerberos authentication fixed for SSL connections in either of the
> versions?
>
>
> Am 08.03.2020 um 21:18 schrieb Erick Erickson :
> >
> > see: SOLR-14312
> >
> > Short form: There have been some CVEs etc. fixed since 3.5.5, but then
> > 3.6.0 was released. Should we upgrade to 3.5.7 or 3.6.0? If 3.6.0, now
> > or wait?
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: 8.5 release

[Joel Bernstein]

Ok, I'll do the backport today. Thanks!

Joel Bernstein
http://joelsolr.blogspot.com/


On Mon, Mar 9, 2020 at 6:21 AM Alan Woodward  wrote:

> Thanks Uwe!
>
> On 7 Mar 2020, at 10:06, Uwe Schindler  wrote:
>
> Hi,
>
> FYI, I cleaned, renamed, and changed the Jenkins Jobs, so the 8.5 branch
> is in the loop on ASF Jenkins and Policeman Jenkins.
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> *From:* Alan Woodward 
> *Sent:* Wednesday, March 4, 2020 5:35 PM
> *To:* dev@lucene.apache.org
> *Subject:* Re: 8.5 release
>
> I’ve created a branch for the 8.5 release (`branch_8_5`) and pushed it to
> the apache repository.  We’re now at feature freeze, so only bug fixes
> should be pushed to the branch.
>
> I can see from
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20priority%20%3D%20Blocker%20AND%20fixVersion%20%3D%208.5%20ORDER%20BY%20priority%20DESC
> 
>  that
> we have 4 tickets marked as Blockers for this release.  I plan to build a
> first release candidate next Monday, which gives us a few days to resolve
> these.  If that’s not going to be long enough, please let me know.
>
> Uwe, Steve, can one of you start the Jenkins tasks for the new branch?
>
> Thanks, Alan
>
>
> On 3 Mar 2020, at 14:50, Alan Woodward  wrote:
>
> PSA: I’ve had to generate a new GPG key for this release, and it takes a
> while for it to get mirrored to the lucene KEYS file.  I’ll hold off
> cutting the branch until everything is ready, so it will probably now be
> tomorrow UK time before I start the release proper.
>
>
> On 25 Feb 2020, at 07:49, Noble Paul  wrote:
>
> +1
>
> On Wed, Feb 19, 2020 at 9:35 PM Ignacio Vera  wrote:
>
>
> +1
>
> On Tue, Feb 18, 2020 at 7:26 PM Jan Høydahl  wrote:
>
>
> +1
>
> That should give us time to update release docs for the new website too.
>
> Jan Høydahl
>
> 18. feb. 2020 kl. 18:28 skrev Adrien Grand :
>
> 
> +1
>
> On Tue, Feb 18, 2020 at 4:58 PM Alan Woodward 
> wrote:
>
>
> Hi all,
>
> It’s been a while since we released lucene-solr 8.4, and we’ve accumulated
> quite a few nice new features since then.  I’d like to volunteer to be a
> release manager for an 8.5 release.  If there's agreement, then I plan to
> cut the release branch two weeks today, on Tuesday 3rd March.
>
> - Alan
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
>
>
>
> --
> Adrien
>
>
>
>
> --
> -
> Noble Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
>
>
>

Re: 8.5 release

[Alan Woodward]

Thanks Uwe!

> On 7 Mar 2020, at 10:06, Uwe Schindler  wrote:
> 
> Hi,
>  
> FYI, I cleaned, renamed, and changed the Jenkins Jobs, so the 8.5 branch is 
> in the loop on ASF Jenkins and Policeman Jenkins.
>  
> Uwe
>  
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de 
> eMail: u...@thetaphi.de 
>  
> From: Alan Woodward  
> Sent: Wednesday, March 4, 2020 5:35 PM
> To: dev@lucene.apache.org
> Subject: Re: 8.5 release
>  
> I’ve created a branch for the 8.5 release (`branch_8_5`) and pushed it to the 
> apache repository.  We’re now at feature freeze, so only bug fixes should be 
> pushed to the branch.
>  
> I can see from 
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20priority%20%3D%20Blocker%20AND%20fixVersion%20%3D%208.5%20ORDER%20BY%20priority%20DESC
>  
> 
>  that we have 4 tickets marked as Blockers for this release.  I plan to build 
> a first release candidate next Monday, which gives us a few days to resolve 
> these.  If that’s not going to be long enough, please let me know.
>  
> Uwe, Steve, can one of you start the Jenkins tasks for the new branch?
>  
> Thanks, Alan
> 
> 
>> On 3 Mar 2020, at 14:50, Alan Woodward > > wrote:
>>  
>> PSA: I’ve had to generate a new GPG key for this release, and it takes a 
>> while for it to get mirrored to the lucene KEYS file.  I’ll hold off cutting 
>> the branch until everything is ready, so it will probably now be tomorrow UK 
>> time before I start the release proper.
>> 
>> 
>>> On 25 Feb 2020, at 07:49, Noble Paul >> > wrote:
>>> 
>>> +1
>>> 
>>> On Wed, Feb 19, 2020 at 9:35 PM Ignacio Vera >> > wrote:
>>> 
 
 +1
 
 On Tue, Feb 18, 2020 at 7:26 PM Jan Høydahl >>> > wrote:
 
> 
> +1
> 
> That should give us time to update release docs for the new website too.
> 
> Jan Høydahl
> 
> 18. feb. 2020 kl. 18:28 skrev Adrien Grand  >:
> 
> 
> +1
> 
> On Tue, Feb 18, 2020 at 4:58 PM Alan Woodward  > wrote:
> 
>> 
>> Hi all,
>> 
>> It’s been a while since we released lucene-solr 8.4, and we’ve 
>> accumulated quite a few nice new features since then.  I’d like to 
>> volunteer to be a release manager for an 8.5 release.  If there's 
>> agreement, then I plan to cut the release branch two weeks today, on 
>> Tuesday 3rd March.
>> 
>> - Alan
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> 
> 
> --
> Adrien
>>> 
>>> 
>>> 
>>> -- 
>>> -
>>> Noble Paul
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>>> 
>>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>>> 

Re: 8.5 release

[Alan Woodward]

Hi Joel,

I’ve got some yaks to shave here before I build the release candidate, so 
please go ahead and backport.

> On 9 Mar 2020, at 01:18, Joel Bernstein  wrote:
> 
> If possible I'd like to backport 
> https://issues.apache.org/jira/browse/SOLR-14073 
>  for the 8.5 release. The 
> work is already committed just waiting on the go ahead for the backport and 
> I'll update CHANGES,txt and close out the ticket.
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> 
> On Sat, Mar 7, 2020 at 5:06 AM Uwe Schindler  > wrote:
> Hi,
> 
>  
> 
> FYI, I cleaned, renamed, and changed the Jenkins Jobs, so the 8.5 branch is 
> in the loop on ASF Jenkins and Policeman Jenkins.
> 
>  
> 
> Uwe
> 
>  
> 
> -
> 
> Uwe Schindler
> 
> Achterdiek 19, D-28357 Bremen
> 
> https://www.thetaphi.de 
> eMail: u...@thetaphi.de 
>  
> 
> From: Alan Woodward mailto:romseyg...@gmail.com>> 
> Sent: Wednesday, March 4, 2020 5:35 PM
> To: dev@lucene.apache.org 
> Subject: Re: 8.5 release
> 
>  
> 
> I’ve created a branch for the 8.5 release (`branch_8_5`) and pushed it to the 
> apache repository.  We’re now at feature freeze, so only bug fixes should be 
> pushed to the branch.
> 
>  
> 
> I can see from 
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20priority%20%3D%20Blocker%20AND%20fixVersion%20%3D%208.5%20ORDER%20BY%20priority%20DESC
>  
> 
>  that we have 4 tickets marked as Blockers for this release.  I plan to build 
> a first release candidate next Monday, which gives us a few days to resolve 
> these.  If that’s not going to be long enough, please let me know.
> 
>  
> 
> Uwe, Steve, can one of you start the Jenkins tasks for the new branch?
> 
>  
> 
> Thanks, Alan
> 
> 
> 
> 
> On 3 Mar 2020, at 14:50, Alan Woodward  > wrote:
> 
>  
> 
> PSA: I’ve had to generate a new GPG key for this release, and it takes a 
> while for it to get mirrored to the lucene KEYS file.  I’ll hold off cutting 
> the branch until everything is ready, so it will probably now be tomorrow UK 
> time before I start the release proper.
> 
> 
> 
> On 25 Feb 2020, at 07:49, Noble Paul  > wrote:
> 
> +1
> 
> On Wed, Feb 19, 2020 at 9:35 PM Ignacio Vera  > wrote:
> 
> 
> 
> +1
> 
> On Tue, Feb 18, 2020 at 7:26 PM Jan Høydahl  > wrote:
> 
> 
> 
> +1
> 
> That should give us time to update release docs for the new website too.
> 
> Jan Høydahl
> 
> 18. feb. 2020 kl. 18:28 skrev Adrien Grand  >:
> 
> 
> +1
> 
> On Tue, Feb 18, 2020 at 4:58 PM Alan Woodward  > wrote:
> 
> 
> 
> Hi all,
> 
> It’s been a while since we released lucene-solr 8.4, and we’ve accumulated 
> quite a few nice new features since then.  I’d like to volunteer to be a 
> release manager for an 8.5 release.  If there's agreement, then I plan to cut 
> the release branch two weeks today, on Tuesday 3rd March.
> 
> - Alan
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 
> --
> Adrien
> 
> 
> 
> 
> -- 
> -
> Noble Paul
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
>  
> 
>  
> 

Re: 8.5 release

[Alan Woodward]

It looks like Robert added the relevant 8.6 section to master in 4360fa750644 
(thanks Robert!) - I’ve been using the release wizard for this process so far 
and either missed a step about pushing this to master or it isn’t in there yet; 
I’ll check and make changes to the wizard if necessary.

> On 6 Mar 2020, at 17:28, Chris Hostetter  wrote:
> 
> 
> : I’ve created a branch for the 8.5 release (`branch_8_5`) and pushed it 
> : to the apache repository.  We’re now at feature freeze, so only bug 
> : fixes should be pushed to the branch.
> 
> I'm a little confused where folks should put stuff in CHANGES.txt right 
> now if it's *NOT* something ready to backport all the way to branch_8_5.
> 
> specifically: branch_8x now has an 8.6 section in CHANGES.txt, but master 
> doesn't ... so if i have a feature (or low priority bug fix that I don't 
> want to rush into 8.5 w/o more review) I'm not sure where/how to record it 
> w/o having weird merge conflicts (or causing weird merge conflicts later0
> 
> 
> -Hoss
> http://www.lucidworks.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Upgrade from 6.2.1. to 8.4.1 HttpSolrCall

[Jan Høydahl]

Questions like this belong to the solr-user mailing list. The dev@ list is for 
discussion internal development.
When you issue your question to that list, you may want to re-phrase with more 
contextual information as to what you are actually trying to achieve (what 
library are you upgrading and why), what you tried, in what environment, with 
what custom plugins and config etc etc.

Jan

> 9. mar. 2020 kl. 03:47 skrev Sergio Bilello :
> 
> Hello! I am trying to perform a library upgrade. I got the following 
> exception. Any advice on how to fix it?
> I am thinking if I should investigate with an heapdump or if some expert 
> already encountered the problem and it is an easy fix to be done.
> I am not using solrcloud but legacy standalone solr app.
> 2020-03-07 00:12:53.182 INFO  
> (searcherExecutor-10-thread-1-processing-x:jobs_es_1) [   x:jobs_es_1] 
> o.a.s.c.SolrCore [jobs_es_1] Registered new searcher 
> Searcher@1ad67899[jobs_es_1] 
> main{ExitableDirectoryReader(UninvertingDirectoryReader())}2020-03-07 
> 00:13:18.908 INFO  (qtp836220863-16) [   ] o.a.s.s.HttpSolrCall [admin] 
> webapp=null path=/admin/cores params={wt=json} status=0 QTime=22020-03-07 
> 00:13:18.909 INFO  (qtp836220863-16) [   ] o.a.s.s.HttpSolrCall Unable to 
> write response, client closed connection or we are shutting down => 
> org.eclipse.jetty.io.EofException: Closed at 
> org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:676)org.eclipse.jetty.io.EofException:
>  Closed at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:676) 
> ~[jetty-server-9.4.19.v20190610.jar:9.4.19.v20190610] at 
> org.apache.solr.servlet.ServletOutputStreamWrapper.write(ServletOutputStreamWrapper.java:126)
>  ~[?:?] at 
> org.apache.solr.response.QueryResponseWriterUtil$1.write(QueryResponseWriterUtil.java:54)
>  ~[?:?] at java.io.OutputStream.write(OutputStream.java:116) ~[?:1.8.0_161] 
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) ~[?:1.8.0_161] 
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) 
> ~[?:1.8.0_161] at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) 
> ~[?:1.8.0_161] at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) 
> ~[?:1.8.0_161] at 
> java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) ~[?:1.8.0_161] 
> at org.apache.solr.common.util.FastWriter.flush(FastWriter.java:136) ~[?:?] 
> at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:66)
>  ~[?:?] at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:892) 
> ~[?:?] at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:812)
>  ~[?:?] at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:558) 
> ~[?:?] at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:419)
>  ~[?:?] at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351)
>  ~[?:?] at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>  ~[jetty-servlet-9.4.19.v20190610.jar:9.4.19.v20190610] at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) 
> ~[jetty-servlet-9.4.19.v20190610.jar:9.4.19.v20190610] at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) 
> ~[jetty-server-9.4.19.v20190610.jar:9.4.19.v20190610] at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) 
> ~[jetty-security-9.4.19.v20190610.jar:9.4.19.v20190610] at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>  ~[jetty-server-9.4.19.v20190610.jar:9.4.19.v20190610] at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>  ~[jetty-server-9.4.19.v20190610.jar:9.4.19.v20190610] at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
>  ~[jetty-server-9.4.19.v20190610.jar:9.4.19.v20190610] at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>  ~[jetty-server-9.4.19.v20190610.jar:9.4.19.v20190610] at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
>  ~[jetty-server-9.4.19.v20190610.jar:9.4.19.v20190610] at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>  ~[jetty-server-9.4.19.v20190610.jar:9.4.19.v20190610] at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) 
> ~[jetty-servlet-9.4.19.v20190610.jar:9.4.19.v20190610] at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
>  ~[jetty-server-9.4.19.v20190610.jar:9.4.19.v20190610] at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>  ~[jetty-server-9.4.19.v20190610.jar:9.4.19.v20190610] at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
>  ~[jetty-server-9.4.19.v20190610.jar:9.4.19.v20190610] at 
>