Started by timer3766c4e4e9b1cf80ebe4c258aba2b0cce16a1bd2d0e5c4e4e9b1cf80ebe4c258aba2b0cce16a1bd2d0e5refs/remotes/origin/mainc4e4e9b1cf80ebe4c258aba2b0cce16a1bd2d0e5c4e4e9b1cf80ebe4c258aba2b0cce16a1bd2d0e5refs/remotes/origin/mainc4e4e9b1cf80ebe4c258aba2b0cce16a1bd2d0e5c4e4e9b1cf80ebe4c258aba2b0cce16a1bd2d0e5refs/remotes/origin/mainhttps://gitbox.apache.org/repos/asf/lucene.git077817691testReportfalseJava: 64bit/hotspot/jdk-26 -XX:+UseCompressedOops -XX:+UseZGC#3766861459649785Lucene-MMAPv2-Windows #37663766falsefalse3766224905SUCCESS1783431215974https://jenkins.thetaphi.de/view/Lucene/job/Lucene-MMAPv2-Windows/3766/Windows VM- lucene/monitor/src/test/org/apache/lucene/monitor/TestForceNoBulkScoringQuery.java062c53046076264cab858527eb79fc9f84945d021783408778000https://jenkins.thetaphi.de/user/noreplynoreplynoreply@github.comFix seed-dependent failure in TestForceNoBulkScoringQuery (#16369)
The sanity check added in #16350 assumes that searching the un-wrapped
ThrowsOnBulkScoreQuery always calls ScorerSupplier#bulkScorer. With
newSearcher(reader) the searcher may be an AssertingIndexSearcher,
whose ScorerSupplier sometimes builds the bulk scorer from scorer()
instead of delegating, so the expected AssertionError is never thrown:
gradlew -p lucene/monitor test --tests TestForceNoBulkScoringQuery \
-Dtests.seed=BDD18A3ADD885193
Use a plain IndexSearcher so the dispatch under test is deterministic.
2026-07-07 09:19:38 +0200062c53046076264cab858527eb79fc9f84945d02Fix seed-dependent failure in TestForceNoBulkScoringQuery (#16369)editlucene/monitor/src/test/org/apache/lucene/monitor/TestForceNoBulkScoringQuery.java
- lucene/core/src/test/org/apache/lucene/index/TestInfoStream.java4c9b5e656743085206b75ebed9b5e2c561ffe0e51783415688000https://jenkins.thetaphi.de/user/noreplynoreplynoreply@github.comFix occasional ConcurrentModificationException in TestInfoStream (#16364)
IndexWriter merge threads might still be writing to the InfoStream
after the writer is closed. Synchronize on the infostream List so
that we don't get CMEs when iterating over it to check messages.
2026-07-07 10:14:48 +01004c9b5e656743085206b75ebed9b5e2c561ffe0e5Fix occasional ConcurrentModificationException in TestInfoStream (#16364)editlucene/core/src/test/org/apache/lucene/index/TestInfoStream.java
- lucene/core/src/java/org/apache/lucene/search/DocValuesRangeIterator.javalucene/core/src/test/org/apache/lucene/search/TestSkipBlockRangeIteratorBitSetOperations.javalucene/core/src/test/org/apache/lucene/search/TestSkipBlockRangeIteratorIntoBitSet.javalucene/CHANGES.txtlucene/core/src/java/org/apache/lucene/search/DenseConjunctionBulkScorer.javalucene/core/src/java/org/apache/lucene/search/TwoPhaseIterator.javalucene/core/src/test/org/apache/lucene/search/TestTwoPhaseIterator.java9b6ca1356f532a252a9e710abf6d4931b96044631783417525000https://jenkins.thetaphi.de/user/noreplynoreplynoreply@github.comAdd TwoPhaseIterator.applyMask() method (#16362)
TwoPhaseIterator.intoBitSet() can vectorize two-phase matching across a
window of documents, but it does not take into account any previous
conjunction clauses that could have excluded documents in the window from
consideration. This can cause inefficiencies in DenseConjunctionBulkScorer,
where we use intoBitSet for windows that we know have more than 25%
matches - for example, a window with 26% matching documents when combined
with a two-phase iterator whose approximation matches everything will
call `match()` on the 74% of documents in the window that have already
been excluded.
This adds a complementary method `applyMask()` to TwoPhaseIterator that
will call matches() on all documents marked as selected in a passed-in
BitSet, and clear them if they do not pass. DocValuesRangeIterator
can use a bulk implementation, while the default implementation
still avoids matching documents already excluded by earlier clauses.
DenseConjunctionBulkScorer always calls applyMask() when presented
with a TwoPhaseIterator as a trailing clause.
2026-07-07 10:45:25 +01009b6ca1356f532a252a9e710abf6d4931b9604463Add TwoPhaseIterator.applyMask() method (#16362)editlucene/core/src/java/org/apache/lucene/search/TwoPhaseIterator.javaaddlucene/core/src/test/org/apache/lucene/search/TestSkipBlockRangeIteratorBitSetOperations.javaaddlucene/core/src/test/org/apache/lucene/search/TestTwoPhaseIterator.javadeletelucene/core/src/test/org/apache/lucene/search/TestSkipBlockRangeIteratorIntoBitSet.javaeditlucene/core/src/java/org/apache/lucene/search/DocValuesRangeIterator.javaeditlucene/CHANGES.txteditlucene/core/src/java/org/apache/lucene/search/DenseConjunctionBulkScorer.java
- lucene/CHANGES.txtlucene/core/src/test/org/apache/lucene/search/TestDenseConjunctionBulkScorer.javalucene/core/src/java/org/apache/lucene/search/DenseConjunctionBulkScorer.javac4e4e9b1cf80ebe4c258aba2b0cce16a1bd2d0e51783427941000https://jenkins.thetaphi.de/user/noreplynoreplynoreply@github.comOrder two-phase iterators in DenseConjunctionBulkScorer by matchCost (#16370)
Currently two-phase iterators are ordered by their approximation
cost. Many two-phase implementations use maxDoc as their approximation,
however, meaning that we don't necessarily get a good ordering
between them and more expensive matches can be called unnecessarily.
This adds an additional comparison layer for two-phase iterators
that orders by matchCost.
2026-07-07 13:39:01 +0100c4e4e9b1cf80ebe4c258aba2b0cce16a1bd2d0e5Order two-phase iterators in DenseConjunctionBulkScorer by matchCost (#16370)editlucene/CHANGES.txteditlucene/core/src/test/org/apache/lucene/search/TestDenseConjunctionBulkScorer.javaeditlucene/core/src/java/org/apache/lucene/search/DenseConjunctionBulkScorer.java
githttps://jenkins.thetaphi.de/user/noreplynoreply