Re: [VOTE] Release Lucene/Solr 8.5.0 RC1

[Andras Salamon]

Hi,

+1 (non-binding)

SUCCESS! [1:32:51.320515]

Andras

On Fri, Mar 13, 2020 at 3:31 PM Alan Woodward  wrote:

> Please vote for release candidate 1 for Lucene/Solr 8.5.0
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.0-RC1-rev7ac489bf7b97b61749b19fa2ee0dc46e74b8dc42
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.0-RC1-rev7ac489bf7b97b61749b19fa2ee0dc46e74b8dc42
>
> The vote will be open for three working days i.e. until next Tuesday,
> 2020-03-18 14:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: 8.5 release

[Andrzej Białecki]

Ok - in the meantime I added it to branch_8x / 8.6.0, so if there’s an RC2 I’ll 
move the CHANGES entry accordingly.

> On 13 Mar 2020, at 14:45, Alan Woodward  wrote:
> 
> Hi Andrzej, sorry to miss this - I’ve just started a vote on RC1 but if that 
> doesn’t pass then we can get this bug fix in.
> 
>> On 12 Mar 2020, at 17:18, Andrzej Białecki > > wrote:
>> 
>> Hi Alan,
>> 
>> Is there still time to merge a fix for SOLR-13264? It’s a bug that makes it 
>> impossible to customise this trigger, you can only config a trigger with its 
>> default operations.
>> 
>>> On 12 Mar 2020, at 17:24, Alan Woodward >> > wrote:
>>> 
>>> While I wait for the smoke tester to finish, I’ve been working on release 
>>> notes.  The ReleaseTodo still refers to the old wiki, and release notes are 
>>> on CWiki now, so I’m flying slightly blind.  Looking at what was done for 
>>> the previous release, I’ve created a draft note for lucene which can be 
>>> inspected and edited here:
>>> 
>>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586
>>>  
>>> 
>>> 
>>> For Solr, the 8.4 release note on CWiki points to a section on 
>>> https://lucene.apache.org/solr/news.html 
>>>   but it’s not entirely clear 
>>> where this section has come from or where it should be drafted.  Can 
>>> anybody enlighten me?
>>> 
 On 11 Mar 2020, at 09:20, Alan Woodward >>> > wrote:
 
 Sure, go ahead
 
> On 10 Mar 2020, at 19:22, David Smiley  > wrote:
> 
> Can I assume it's no big deal to post a solr-ref-guide documentation 
> improvement on the release branch irrespective of whenever you precisely 
> do the RC?
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Tue, Mar 10, 2020 at 9:15 AM Joel Bernstein  > wrote:
> I just updated solr/CHANGES.txt as I missed something. If you've already 
> created the RC then it will be there in case of a respin.
> 
> 
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> 
> On Tue, Mar 10, 2020 at 5:45 AM Ignacio Vera  > wrote:
> done. Thank you!
> 
> On Tue, Mar 10, 2020 at 10:43 AM Alan Woodward  > wrote:
> Go ahead, I’ll start the release build once it’s in.
> 
>> On 10 Mar 2020, at 07:26, Ignacio Vera > > wrote:
>> 
>> Hi Alanm
>> 
>> Is it  possible to backport 
>> https://issues.apache.org/jira/browse/LUCENE-9263 
>>  for the 8.5 release, 
>> I push it tester day and CI is happy.
>> 
>> Thanks,
>> 
>> On Tue, Mar 10, 2020 at 2:35 AM Joel Bernstein > > wrote:
>> 
>> 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 
>>> 

[VOTE] Release Lucene/Solr 8.5.0 RC1

[Alan Woodward]

Please vote for release candidate 1 for Lucene/Solr 8.5.0

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.0-RC1-rev7ac489bf7b97b61749b19fa2ee0dc46e74b8dc42

You can run the smoke tester directly with this command:

python3 -u dev-tools/scripts/smokeTestRelease.py \
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.0-RC1-rev7ac489bf7b97b61749b19fa2ee0dc46e74b8dc42

The vote will be open for three working days i.e. until next Tuesday, 
2020-03-18 14:00 UTC.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Here is my +1
-
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]

That’s the one, thank you Jan!  I’ve cloned it and made minimal changes to 
update it to 8.5, it still needs the release highlights adding in though.  
Draft page is available here:
https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641910=8a43c9fb-6845-413a-b6cd-876a6647bb32=shareui=1584107316180
 


We should definitely make a top-level page for these, they currently sit under 
‘Old Wiki’ which doesn’t seem right at all.

> On 13 Mar 2020, at 11:20, Jan Høydahl  > wrote:
> 
> Perhaps this is the one you are looking for? 
> https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote84 
> 
> 
> We should probably make a top-level page «Release Notes» under which we can 
> attach future release notes.
> 
> Jan
> 
>> 12. mar. 2020 kl. 17:24 skrev Alan Woodward > >:
>> 
>> While I wait for the smoke tester to finish, I’ve been working on release 
>> notes.  The ReleaseTodo still refers to the old wiki, and release notes are 
>> on CWiki now, so I’m flying slightly blind.  Looking at what was done for 
>> the previous release, I’ve created a draft note for lucene which can be 
>> inspected and edited here:
>> 
>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586
>>  
>> 
>> 
>> For Solr, the 8.4 release note on CWiki points to a section on 
>> https://lucene.apache.org/solr/news.html 
>>   but it’s not entirely clear 
>> where this section has come from or where it should be drafted.  Can anybody 
>> enlighten me?
>> 
>>> On 11 Mar 2020, at 09:20, Alan Woodward >> > wrote:
>>> 
>>> Sure, go ahead
>>> 
 On 10 Mar 2020, at 19:22, David Smiley >>> > wrote:
 
 Can I assume it's no big deal to post a solr-ref-guide documentation 
 improvement on the release branch irrespective of whenever you precisely 
 do the RC?
 
 ~ David Smiley
 Apache Lucene/Solr Search Developer
 http://www.linkedin.com/in/davidwsmiley 
 
 
 On Tue, Mar 10, 2020 at 9:15 AM Joel Bernstein >>> > wrote:
 I just updated solr/CHANGES.txt as I missed something. If you've already 
 created the RC then it will be there in case of a respin.
 
 
 
 Joel Bernstein
 http://joelsolr.blogspot.com/ 
 
 
 On Tue, Mar 10, 2020 at 5:45 AM Ignacio Vera >>> > wrote:
 done. Thank you!
 
 On Tue, Mar 10, 2020 at 10:43 AM Alan Woodward >>> > wrote:
 Go ahead, I’ll start the release build once it’s in.
 
> On 10 Mar 2020, at 07:26, Ignacio Vera  > wrote:
> 
> Hi Alanm
> 
> Is it  possible to backport 
> https://issues.apache.org/jira/browse/LUCENE-9263 
>  for the 8.5 release, 
> I push it tester day and CI is happy.
> 
> Thanks,
> 
> On Tue, Mar 10, 2020 at 2:35 AM Joel Bernstein  > wrote:
> 
> 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 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 

Re: 8.5 release

[Alan Woodward]

Hi Andrzej, sorry to miss this - I’ve just started a vote on RC1 but if that 
doesn’t pass then we can get this bug fix in.

> On 12 Mar 2020, at 17:18, Andrzej Białecki  wrote:
> 
> Hi Alan,
> 
> Is there still time to merge a fix for SOLR-13264? It’s a bug that makes it 
> impossible to customise this trigger, you can only config a trigger with its 
> default operations.
> 
>> On 12 Mar 2020, at 17:24, Alan Woodward > > wrote:
>> 
>> While I wait for the smoke tester to finish, I’ve been working on release 
>> notes.  The ReleaseTodo still refers to the old wiki, and release notes are 
>> on CWiki now, so I’m flying slightly blind.  Looking at what was done for 
>> the previous release, I’ve created a draft note for lucene which can be 
>> inspected and edited here:
>> 
>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586
>>  
>> 
>> 
>> For Solr, the 8.4 release note on CWiki points to a section on 
>> https://lucene.apache.org/solr/news.html 
>>   but it’s not entirely clear 
>> where this section has come from or where it should be drafted.  Can anybody 
>> enlighten me?
>> 
>>> On 11 Mar 2020, at 09:20, Alan Woodward >> > wrote:
>>> 
>>> Sure, go ahead
>>> 
 On 10 Mar 2020, at 19:22, David Smiley >>> > wrote:
 
 Can I assume it's no big deal to post a solr-ref-guide documentation 
 improvement on the release branch irrespective of whenever you precisely 
 do the RC?
 
 ~ David Smiley
 Apache Lucene/Solr Search Developer
 http://www.linkedin.com/in/davidwsmiley 
 
 
 On Tue, Mar 10, 2020 at 9:15 AM Joel Bernstein >>> > wrote:
 I just updated solr/CHANGES.txt as I missed something. If you've already 
 created the RC then it will be there in case of a respin.
 
 
 
 Joel Bernstein
 http://joelsolr.blogspot.com/ 
 
 
 On Tue, Mar 10, 2020 at 5:45 AM Ignacio Vera >>> > wrote:
 done. Thank you!
 
 On Tue, Mar 10, 2020 at 10:43 AM Alan Woodward >>> > wrote:
 Go ahead, I’ll start the release build once it’s in.
 
> On 10 Mar 2020, at 07:26, Ignacio Vera  > wrote:
> 
> Hi Alanm
> 
> Is it  possible to backport 
> https://issues.apache.org/jira/browse/LUCENE-9263 
>  for the 8.5 release, 
> I push it tester day and CI is happy.
> 
> Thanks,
> 
> On Tue, Mar 10, 2020 at 2:35 AM Joel Bernstein  > wrote:
> 
> 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 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
>>  
>> 

Re: Solr - very long core admin timeouts

[David Smiley]

Thanks for sharing this with us and debugging this reasonably far.

If this happens when a replica is being added, then this makes sense to me
because the replica isn't ready yet to respond with a searcher.
Conditionally if the replica is in recovery, then maybe don't ask for the
indexInfo?

I can see room for improvement in Solr here.  The core admin stats don't
actually need an IndexSearcher, it needs a DirectoryReader which is much
cheaper to get.  Even SolrCore.getIndexSize creates/closes one on the fly.
I filed an issue:
https://issues.apache.org/jira/browse/SOLR-14325

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


On Fri, Mar 13, 2020 at 8:50 AM Richard Goodman 
wrote:

> Hi there,
>
> I went to a Solr meetup in London a month or two ago, and asked this
> question then, however, people weren't fully sure what the underlying issue
> was and were curious to know.
>
> - Background of our tech stack
>
> Where I work, we run just under 30 solr clusters in our live environment:
>
>- Most of our clusters have the upper limit capacity of around 100TB,
>but typically our used capacity per cluster is around 55% on average.
>- Most of our clusters are running 96 instances, if not more.
>- Each instance has a TB of storage,
>- Most of our clusters have 322 collections, where each collection is
>split into 16 shards and 3-way replication
>- Each core is on average 20GB, some going up to 40GB.
>- We are currently running solr v7.7.2
>
>
> We've been dealing with an issue with running Solr Cloud to this size for
> quite some time, whilst it's never caused a catastrophic failure, when it
> comes to us wanting to improve our monitoring, it can become quite a
> blocker for us.
>
> - The issue
>
> We use the core admin API a lot, to get information on core level metrics.
> However, if there are cores recovering, this will lock and slow down the
> API massively, sometimes minutes to get a response from said API.
>
> I worked on implementing the solr prometheus exporter to provide us vision
> on our clusters, however, because of the core admin timeout, I am met with
> tons of errors within the application and unable to collect core level
> metrics. Similarly, if we use the metrics api for the node level metrics
> and core level metrics, it will take a very long time to return results.
>
> - Any findings so far
>
> We discovered that if you supply "=false" to the core api call,
> it will return instantly, but of course you miss some information that is
> quite useful. We have potentially identified where in a jstack the issue is
> occuring, as quoted from a colleague:
>
> "Had a look at the code from my stack trace, as we expected it's waiting
> for the index to be opened to populate the info about numDocs etc, for the
> Core admin API call"
>
> However, not entirely sure what the best approach to fixing this is? We
> were also curious if other people are getting a similar issue?
>
> - Evidence
>
> I created a small dev cluster in our tech stack, and loaded a 30GB backup,
> where each core is around 2GB big on average. I then just ran a time on a
> curl of the core admin api;
>
> *Call before a replica being added:*
>
> root @ rich-solr0.dev-cluster.net ~ # time curl -s 
> "http://localhost:8080/solr/admin/cores; > core_admin_pre.outreal  0m0.070s
> user  0m0.008s
> sys   0m0.008s
>
>
> *Call during a replica being added:*
>
> root @ rich-solr1.dev-cluster.net ~ # time curl -s 
> "http://localhost:8080/solr/admin/cores; > core_admin_during.outreal   
> 0m8.130s
> user  0m0.016s
> sys   0m0.008s
>
>
>
> *Call after a replica being added:*
>
> root @ rich-solr1.dev-cluster.net ~ # time curl -s 
> "http://localhost:8080/solr/admin/cores; > core_admin_done.out
>
> real  0m0.037s
>
> user  0m0.008s
>
> sys   0m0.012s
>
>
> I know here, that the difference is only 8 seconds, however, this is only
> with 2GB cores, in our live environment, it's significantly larger.
>
> I have also collected a bunch of jstacks that are before, during and after
> this occurring, where a previous colleague quoted the following being a
> possible root cause:
>
> "qtp511717113-1006" #1006 prio=5 os_prio=0 tid=0x7f465800a000 nid=0xc709 
> in Object.wait() [0x7f6b2f954000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2206)
> - locked <0x0004d1d75af0> (a java.lang.Object)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1994)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1868)
> at 
> org.apache.solr.handler.admin.CoreAdminOperation.getCoreStatus(CoreAdminOperation.java:339)
> at org.apache.solr.handler.admin.StatusOp.execute(StatusOp.java:46)
> at 
> 

Solr - very long core admin timeouts

[Richard Goodman]

Hi there,

I went to a Solr meetup in London a month or two ago, and asked this
question then, however, people weren't fully sure what the underlying issue
was and were curious to know.

- Background of our tech stack

Where I work, we run just under 30 solr clusters in our live environment:

   - Most of our clusters have the upper limit capacity of around 100TB,
   but typically our used capacity per cluster is around 55% on average.
   - Most of our clusters are running 96 instances, if not more.
   - Each instance has a TB of storage,
   - Most of our clusters have 322 collections, where each collection is
   split into 16 shards and 3-way replication
   - Each core is on average 20GB, some going up to 40GB.
   - We are currently running solr v7.7.2


We've been dealing with an issue with running Solr Cloud to this size for
quite some time, whilst it's never caused a catastrophic failure, when it
comes to us wanting to improve our monitoring, it can become quite a
blocker for us.

- The issue

We use the core admin API a lot, to get information on core level metrics.
However, if there are cores recovering, this will lock and slow down the
API massively, sometimes minutes to get a response from said API.

I worked on implementing the solr prometheus exporter to provide us vision
on our clusters, however, because of the core admin timeout, I am met with
tons of errors within the application and unable to collect core level
metrics. Similarly, if we use the metrics api for the node level metrics
and core level metrics, it will take a very long time to return results.

- Any findings so far

We discovered that if you supply "=false" to the core api call,
it will return instantly, but of course you miss some information that is
quite useful. We have potentially identified where in a jstack the issue is
occuring, as quoted from a colleague:

"Had a look at the code from my stack trace, as we expected it's waiting
for the index to be opened to populate the info about numDocs etc, for the
Core admin API call"

However, not entirely sure what the best approach to fixing this is? We
were also curious if other people are getting a similar issue?

- Evidence

I created a small dev cluster in our tech stack, and loaded a 30GB backup,
where each core is around 2GB big on average. I then just ran a time on a
curl of the core admin api;

*Call before a replica being added:*

root @ rich-solr0.dev-cluster.net ~ # time curl -s
"http://localhost:8080/solr/admin/cores; >
core_admin_pre.outreal  0m0.070s
user0m0.008s
sys 0m0.008s


*Call during a replica being added:*

root @ rich-solr1.dev-cluster.net ~ # time curl -s
"http://localhost:8080/solr/admin/cores; >
core_admin_during.outreal   0m8.130s
user0m0.016s
sys 0m0.008s



*Call after a replica being added:*

root @ rich-solr1.dev-cluster.net ~ # time curl -s
"http://localhost:8080/solr/admin/cores; > core_admin_done.out

real0m0.037s

user0m0.008s

sys 0m0.012s


I know here, that the difference is only 8 seconds, however, this is only
with 2GB cores, in our live environment, it's significantly larger.

I have also collected a bunch of jstacks that are before, during and after
this occurring, where a previous colleague quoted the following being a
possible root cause:

"qtp511717113-1006" #1006 prio=5 os_prio=0 tid=0x7f465800a000
nid=0xc709 in Object.wait() [0x7f6b2f954000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2206)
- locked <0x0004d1d75af0> (a java.lang.Object)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1994)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1868)
at 
org.apache.solr.handler.admin.CoreAdminOperation.getCoreStatus(CoreAdminOperation.java:339)
at org.apache.solr.handler.admin.StatusOp.execute(StatusOp.java:46)
at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:180)


The stacktraces can be found here
.

If anyone has any advice, that would be greatly appreciated.

Cheers,
-- 

Richard Goodman

Re: 8.5 release

[Jan Høydahl]

Perhaps this is the one you are looking for? 
https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote84

We should probably make a top-level page «Release Notes» under which we can 
attach future release notes.

Jan

> 12. mar. 2020 kl. 17:24 skrev Alan Woodward :
> 
> While I wait for the smoke tester to finish, I’ve been working on release 
> notes.  The ReleaseTodo still refers to the old wiki, and release notes are 
> on CWiki now, so I’m flying slightly blind.  Looking at what was done for the 
> previous release, I’ve created a draft note for lucene which can be inspected 
> and edited here:
> 
> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586
>  
> 
> 
> For Solr, the 8.4 release note on CWiki points to a section on 
> https://lucene.apache.org/solr/news.html 
>   but it’s not entirely clear where 
> this section has come from or where it should be drafted.  Can anybody 
> enlighten me?
> 
>> On 11 Mar 2020, at 09:20, Alan Woodward > > wrote:
>> 
>> Sure, go ahead
>> 
>>> On 10 Mar 2020, at 19:22, David Smiley >> > wrote:
>>> 
>>> Can I assume it's no big deal to post a solr-ref-guide documentation 
>>> improvement on the release branch irrespective of whenever you precisely do 
>>> the RC?
>>> 
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley 
>>> 
>>> 
>>> On Tue, Mar 10, 2020 at 9:15 AM Joel Bernstein >> > wrote:
>>> I just updated solr/CHANGES.txt as I missed something. If you've already 
>>> created the RC then it will be there in case of a respin.
>>> 
>>> 
>>> 
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/ 
>>> 
>>> 
>>> On Tue, Mar 10, 2020 at 5:45 AM Ignacio Vera >> > wrote:
>>> done. Thank you!
>>> 
>>> On Tue, Mar 10, 2020 at 10:43 AM Alan Woodward >> > wrote:
>>> Go ahead, I’ll start the release build once it’s in.
>>> 
 On 10 Mar 2020, at 07:26, Ignacio Vera >>> > wrote:
 
 Hi Alanm
 
 Is it  possible to backport 
 https://issues.apache.org/jira/browse/LUCENE-9263 
  for the 8.5 release, I 
 push it tester day and CI is happy.
 
 Thanks,
 
 On Tue, Mar 10, 2020 at 2:35 AM Joel Bernstein >>> > wrote:
 
 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 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 

Secure communication between Solr and Zookeeper

[Kirk Fitzsimons]

Is it possible to secure communication between Solr(8.3.1) and Zookeeper
(3.5.5)?

We have followed the guide
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User
+Guide

When we try the below command it hangs and fails to connect to zookeeper.

solr/server/scripts/cloud-scripts$ ./zkcli.sh -zkhost localhost:2281 -cmd
ls
INFO  - 2020-03-12 14:08:41.438;
org.apache.solr.common.cloud.ConnectionManager; Waiting for client to
connect to ZooKeeper

In the zookeeper logs we can see the following error:

io.netty.handler.codec.DecoderException:
io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record

Kirk Fitzsimons