I ran the solr/core tests few times, and here are the results: 1) [junit4] Tests with failures [seed: 7A919DB0B1698A5]: [junit4] - org.apache.solr.search.TestRecoveryHdfs (suite) [junit4]
2) BUILD SUCCESSFUL Total time: 4 minutes 31 seconds 3) [junit4] Tests with failures [seed: E174107AF681900D]: [junit4] - org.apache.solr.filestore.TestDistribPackageStore.testPackageStoreManagement [junit4] - org.apache.solr.cloud.hdfs.HdfsRecoverLeaseTest (suite) 4) [junit4] Tests with failures [seed: 6135443D8851EC4F]: [junit4] - org.apache.solr.store.hdfs.HdfsDirectoryTest (suite) [junit4] - org.apache.solr.cloud.hdfs.HdfsRecoverLeaseTest (suite) 5) [junit4] Tests with failures [seed: 967F9EA7B1CB4A4F]: [junit4] - org.apache.solr.index.hdfs.CheckHdfsIndexTest (suite) [junit4] - org.apache.solr.cloud.hdfs.HdfsNNFailoverTest (suite) 6) [junit4] Tests with failures [seed: 22B4F78C758D19E4]: [junit4] - org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore (suite) I think the frequency of these HDFS failures have increased since the Hadoop upgrade 3.2.2 -> 3.2.4 ( https://github.com/apache/lucene-solr/commit/3cf0a5501084c9e3d0e53657a20477007f33755a ). Any ideas, please, on how to deal with them? On Wed, 24 Jan 2024 at 07:12, Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > Looking at it, ASAP. > > On Wed, 24 Jan, 2024, 2:07 am Houston Putman, <hous...@apache.org> wrote: > >> Right now we are blocked on >> https://issues.apache.org/jira/browse/SOLR-16580, >> which introduced failures that pop up roughly 50% of the time or so. >> >> We can't really proceed until the issue is fixed, as I don't think it's >> necessarily a test issue. >> >> - Houston >> >> On Sun, Jan 21, 2024 at 10:10 PM Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com> wrote: >> >> > +1 >> > >> > On Sun, 21 Jan, 2024, 8:47 am Houston Putman, <hous...@apache.org> >> wrote: >> > >> > > Now that 9.4 is out, we should plan this for next week. Ill try to get >> > > stuff ready for a monday RC, if no one objects. >> > > >> > > - Houston >> > > >> > > On Tue, Jan 16, 2024 at 12:58 PM Houston Putman < >> houstonput...@gmail.com >> > > >> > > wrote: >> > > >> > > > Since the 9.4.1 release candidate is out, I'm fine waiting for it to >> > > > finish. But let's try to get 8.11.3 out very soon afterwards. >> > > > >> > > > Also, as I stated on the other thread, didn't mean to tread on your >> > toes >> > > > here. If you want to continue with the release, please do! >> > > > >> > > > - Houston >> > > > >> > > > On Sat, Jan 13, 2024 at 8:59 AM Ishan Chattopadhyaya < >> > > > ichattopadhy...@gmail.com> wrote: >> > > > >> > > >> Shouldn't we wait for the 9.4.1 to go out first? That's what I was >> > > holding >> > > >> out on. >> > > >> >> > > >> On Sat, 13 Jan, 2024, 12:43 am Houston Putman, <hous...@apache.org >> > >> > > >> wrote: >> > > >> >> > > >> > NOTICE: >> > > >> > >> > > >> > I am now preparing for a bugfix release from branch branch_8_11 >> > > >> > >> > > >> > Please observe the normal rules for committing to this branch: >> > > >> > >> > > >> > * Before committing to the branch, reply to this thread and argue >> > > >> > why the fix needs backporting and how long it will take. >> > > >> > * All issues accepted for backporting should be marked with >> 8.11.3 >> > > >> > in JIRA, and issues that should delay the release must be >> marked >> > as >> > > >> > Blocker >> > > >> > * All patches that are intended for the branch should first be >> > > committed >> > > >> > to the unstable branch, merged into the stable branch, and then >> > into >> > > >> > the current release branch. >> > > >> > * Only Jira issues with Fix version 8.11.3 and priority "Blocker" >> > will >> > > >> > delay >> > > >> > a release candidate build. >> > > >> > >> > > >> >> > > > >> > > >> > >> >
