> The failure seems to be because of a timeout during collection
> creation

Thanks for digging in. Seems like that is the exact class of fix that we
did for SOLR-15138 and are planning for 8.8.2. Shall we backport that fix
to the release branch now (for RC2 or 8.8.2)?

> My h/w is really fast and beefy and may be that's why it doesn't get
reproduced.
Same here, Ryzen 9 5950X (fastest mainstream CPU out there).

On Tue, Feb 16, 2021 at 5:36 PM Michael McCandless <
luc...@mikemccandless.com> wrote:

> Curious, the smoke tester passed for me on the first try:
>
> SUCCESS! [0:44:29.979512]
>
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Sun, Feb 14, 2021 at 11:26 AM Timothy Potter <thelabd...@apache.org>
> wrote:
>
>> Please vote for release candidate 1 for Lucene/Solr 8.8.1
>>
>>
>> The artifacts can be downloaded from:
>>
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
>>
>>
>> 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.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
>>
>>
>> The vote will be open for at least 72 hours i.e. until 2021-02-17 17:00
>> UTC.
>>
>>
>> Here is my +1 ~ SUCCESS! [0:50:06.728441]
>>
>>
>> In addition to the smoke test, I built a Docker image from
>> solr-8.8.1.tgz locally and verified:
>>
>>
>> a. A rolling upgrade of a 3-node 8.7.0 cluster to the 8.8.1 RC completes
>> successfully w/o any NPEs or weirdness with leader election / recoveries.
>>
>>
>> b. The base_url property is stored in replica state after the upgrade
>>
>>
>> c. A basic client application built with SolrJ 8.7.0 can load cluster
>> state info directly from ZK and query the 8.8.1 RC1 servers.
>>
>>
>> d. Same client app built with SolrJ 8.8.0 works as well.
>>
>>
>> As this bug-fix release is primarily needed to address a SolrJ
>> back-compat break (SOLR-15145) and unfortunately our smoke tester framework 
>> does
>> not test for backcompat of older SolrJ against the RC, I ask others to
>> please test rolling upgrades of servers (ideally multi-node clusters)
>> running pre-8.8.0 to this RC if possible. Also, please try client
>> applications that are using an older SolrJ, esp. those that load cluster
>> state directly from ZK.
>>
>>
>> Best regards,
>>
>> Tim
>>
>>
>>
>>
>>

Reply via email to