I'm unsure about the hdfs issues for now.. But the "CloudAuthStreamTest" test fails 100% of the time with the "F8952559841D5C83" seed for me. And it's not a test issue, its an actual bug.
I've been focusing my efforts here, but it fails both with PRS enabled and disabled. So the patch went beyond just adjusting how PRS is handled. Honestly at this point I'm not sure what is the cause, and I can't really put more time into it. I'll leave the rest of my findings on the JIRA. - Houston On Tue, Jan 23, 2024 at 8:53 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > 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. > >> > > >> > > >> > > >> > >> > > > > >> > > > >> > > >> > > >
