We have a number of IntervalsSource implementations where automatic minimization of
disjunctions can lead to surprising results:
* PHRASE queries can miss matches because a longer matching sub-source is minimized
away, leaving a gap
* MAXGAPS queries can miss matches for the same reason
* CONTAINING, NOT_CONTAINING, CONTAINED_BY and NOT_CONTAINED_BY queries
can miss matches if the 'big' interval gets minimized
The proper way to deal with this is to rewrite the queries by pulling disjunctions to the top
of the query tree, so that PHRASE("a", OR(PHRASE("b", "c"), "c")) is rewritten to
OR(PHRASE("a", "b", "c"), PHRASE("a", "c")). To be able to do this generally, we need to
add a new pullUpDisjunctions() method to IntervalsSource that performs this rewriting
for each source that it would apply to.
Because these rewritten queries will in general be less efficient due to the duplication of
effort (eg the rewritten PHRASE query above pulls 5 term iterators rather than 4 in the
original), we also add an option to Intervals.or() that will prevent this happening, so that
consumers can choose speed over accuracy if it suits their usecase.
FilterDirectory.getPendingDeletions() did not delegate the call, which
resulted in a new IndexWriter on same directory not considering pending
delete files. This could in turn result in a FileAlreadyExistsException
when running windows.
Today we never load FSTs of ID-like fields off-heap since we need
very fast access for updates. Yet, a reader that is not loaded from
an IndexWriter can also leave the FST on disk. This change adds
this information to SegmentReadState to allow the postings format
to make this decision without configuration.
Related JIRAs:
* SOLR-11010
* SOLR-11381
* SOLR-12040
* SOLR-13297
Changes:
* Consolidate hdfs configuration into HdfsTestUtil
* Ensure socketTimeout long enough for HDFS tests
* Ensure HdfsTestUtil.getClientConfiguration used in tests
* Replace deprecated HDFS calls
* Use try-with-resources to ensure closing of HDFS resources
Signed-off-by: Kevin Risden <krisden@apache.org>
also decrease the number of iters while increase the cluster shape wait time to reduce the risk of spurious failures on machines under heavy contention w/o making the the test any slower on average
There are 3 tightly related bug fixes in these changes:
1) ConcurrentModificationExceptions were being thrown by some SimClusterStateProvider methods when
creating collections/replicas due to the use of ArrayLists nodeReplicaMap. These ArrayLists were changed
to use synchronizedList wrappers.
2) The Exceptions from #1 were being swallowed/hidden by code using SimCloudManager.submit() w/o checking
the result of the resulting Future object. (As a result, tests waiting for a particular ClusterShape
would timeout regardless of how long they waited.) To protect against "silent" failures like this,
this SimCloudManager.submit() has been updated to wrap all input Callables such that any uncaught errors
will be logged and "counted." SimSolrCloudTestCase will ensure a suite level failure if any such failures
are counted.
3) The changes in #2 exposed additional concurrency problems with the Callables involved in leader election:
These would frequently throw IllegalStateExceptions due to assumptions about the state/existence of
replicas when the Callables were created vs when they were later run -- notably a Callable may have been
created that held a reference to a Slice, but by the time that Callable was run the collection (or a
node, etc...) refered to by that Slice may have been deleted. While fixing this, the leader election
logic was also cleaned up such that adding a replica only triggers leader election for that shard, not
every shard in the collection.
While auditing this code, cleanup was also done to ensure all usage of SimClusterStateProvider.lock was
also cleaned up to remove all risky points where an exception may have been possible after aquiring the
lock but before the try/finally that ensured it would be unlocked.
This commit adds an introspection API to Query, allowing users to traverse
the nested structure of a query and examine its leaves. It replaces the existing
`extractTerms` method on Weight, and alters some highlighting code to use
the new API
This is a spinn-off from `LUCENE-8700` that is satisfied by IndexWriter#flushNextBuffer.
The idea here is to additionally call flushNextBuffer in RandomIndexWriter for better
test coverage. This is a test-only change.