Hi,
I encountered weird race conditions when playing with MergePolicy and
various cache-related SolrEventListener and I don't even know if it's a
bug or a feature that I should compose with. I don't event know if my
question actually belong to this list (it begins with Lucene stuff and
ends with actual Solr use case). Sorry if it's not the case.
To remove another possible race condition, I removed auto-commits for my
tests.
Let's suppose that I have several commits :
commit1 (leading to creation of segment _0)
commit2 (leading to creation of segment _1)
commit3 (leading to creation of segment _2)
And that the MergePolicy decides, for whatever reason, that its time
during commit3 to perform a point-in-time merge (creating the segment _3
which is the result of the merge of the 3 other segments).
a) If the MergePolicy is very slow, the commit3 ends before the merge,
and a new SolrIndexSearcher is created with segments _0, _1, _2 and the
merged segment _3 is left unused, until a possible future commit4, which
may or may not occur.
b) if the MergePolicy is quick enough (or if I use a
SerialMergeScheduler), the merge ends before commit3 and a new
SolrIndexSearcher with the single segment _3, "hiding" (from an
eventListener POV) the segment _2 creation (the postCommit callback is
called, but with an already merged reader).
My application heavily rely on a segment-based cache filled at searcher
creation time in a SolrEventListener, and it happens that with this
non-deterministic behaviour, I sometime "lose" some flushed segments
creation.
Could you tell me if the observed behaviour is definitely normal and
that I should learn to deal with it ? Is there a way to listen to such
behaviour or to have a callback called ?
Thanks in advance for your explanations, and sorry if the above is not
very clear...
Best regards,
Cédric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org
