I filed this: https://github.com/apache/lucene/issues/14315
Seems like a legitimate problem somewhere because this test is awfully slow sometimes, at least on Linux. Dawid On Thu, Feb 27, 2025 at 1:32 PM Dawid Weiss <dawid.we...@gmail.com> wrote: > > I ran it on Linux and this indeed takes an awful long time - I terminated > it after 4 minutes: > > ./gradlew :lucene:misc:test --tests > "org.apache.lucene.misc.store.TestDirectIODirectory" -Ptests.jvms=4 > -Ptests.jvmargs= -Ptests.seed=DEE483D0402DBE52 -Ptests.multiplier=2 > -Ptests.useSecurityManager=true -Ptests.nightly=true -Ptests.gui=true > -Ptests.file.encoding=UTF-8 -Ptests.vectorsize=512 > -Ptests.forceintegervectors=true > > D. > > On Thu, Feb 27, 2025 at 12:47 PM Dawid Weiss <dawid.we...@gmail.com> > wrote: > >> >> >>> This does not reproduce for me :-( I’ll keep trying… >>> >> >> Those CI servers are slow... These timeout failures are often hard to >> understand. But a timeout of 7200 secs is long enough to be worried. >> >> >>> It’s a little worrying, since I did make changes to DirectIODirectory >>> recently. https://github.com/apache/lucene/issues/14106 >> >> >> This may be completely unrelated. For what it's worth, the test log >> contains a stack trace forced before the test runner abandons the test. It >> then tries >> to terminate/ interrupt all the threads that have been started since the >> test's began running. This is also interesting because it couldn't >> terminate this thread: >> >> 2> WARNING: Will linger awaiting termination of 1 leaked thread(s). >> 2> Fra 27, 2025 1:55:41 PM >> com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks >> 2> SEVERE: 1 thread leaked from SUITE scope at >> org.apache.lucene.misc.store.TestDirectIODirectory: >> 2> 1) Thread[id=27, >> name=TEST-TestDirectIODirectory.testRandomByte-seed#[DEE483D0402DBE52], >> state=RUNNABLE, group=TGRP-TestDirectIODirectory] >> 2> at java.base/sun.nio.ch.UnixFileDispatcherImpl.pread0(Native >> Method) >> 2> at >> java.base/sun.nio.ch.UnixFileDispatcherImpl.pread(UnixFileDispatcherImpl.java:57) >> 2> at >> java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:338) >> 2> at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:294) >> 2> at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:283) >> 2> at >> java.base/sun.nio.ch.FileChannelImpl.readInternal(FileChannelImpl.java:984) >> 2> at >> java.base/sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:967) >> 2> at org.apache.lucene.test_framework@11.0.0-SNAPSHOT >> /org.apache.lucene.tests.mockfile.FilterFileChannel.read(FilterFileChannel.java:108) >> 2> at org.apache.lucene.test_framework@11.0.0-SNAPSHOT >> /org.apache.lucene.tests.mockfile.FilterFileChannel.read(FilterFileChannel.java:108) >> 2> at org.apache.lucene.test_framework@11.0.0-SNAPSHOT >> /org.apache.lucene.tests.mockfile.FilterFileChannel.read(FilterFileChannel.java:108) >> 2> at >> org.apache.lucene.misc.store.DirectIODirectory$DirectIOIndexInput.refill(DirectIODirectory.java:446) >> 2> at >> org.apache.lucene.misc.store.DirectIODirectory$DirectIOIndexInput.seekInternal(DirectIODirectory.java:387) >> 2> at >> org.apache.lucene.misc.store.DirectIODirectory$DirectIOIndexInput.seek(DirectIODirectory.java:376) >> 2> at org.apache.lucene.core@11.0.0-SNAPSHOT >> /org.apache.lucene.store.IndexInput$1.readByte(IndexInput.java:178) >> 2> at org.apache.lucene.test_framework@11.0.0-SNAPSHOT >> /org.apache.lucene.tests.store.BaseDirectoryTestCase.assertBytes(BaseDirectoryTestCase.java:1165) >> 2> at org.apache.lucene.test_framework@11.0.0-SNAPSHOT >> /org.apache.lucene.tests.store.BaseDirectoryTestCase.testRandomByte(BaseDirectoryTestCase.java:1138) >> >> It looks like it's stuck somewhere in the native code. Weird. >> >> Dawid >> >
