Still, I think that using CopyOnWriteArrayList is best here.
OK I'll switch back to COWAL... it makes me nervous though. I like
being defensive and the added cost of CHM iteration really should be
I'd like even more for there to be just a single CopyOnWriteArrayList per "top-level" reader that is then propagated to all sub/segment readers, including new ones on a reopen. But I guess Mike indicated that was currently too hard/hairy.
This did get hairy... eg if you make a MultiReader (or ParallelReader)
w/ subs... what should happen to their listeners? Ie what if the subs
already have listeners enrolled?
It also spooked me that apps may think they have to re-register after
re-open (if we stick w/ ArrayList) since then the list'd just grow...
And, if you pull an NRT reader from IW (which is what reopen does
under the hood for an NRT reader), how to share its listeners? Ie,
we'd have to add a setter to IW as well, so it's also "single source"
(propagates on reopen).
This is why I fell back to a simple static as the baby step for now.
The static is really non-optimal though - among other problems, it requires systems with multiple readers (and wants to do different things with different readers, such as maintain separate caches) to figure out what top-level reader a segment reader is associated with. And given that we are dealing with IndexReader instances in the callbacks, and not ReaderContext objects, this seems impossible?
ReaderContext doesn't really make sense here?
Ie, the listener is invoked when any/all composite readers sharing a
given segment have now closed (ie when the RC for that segment's core
drops to 0), or when a composite reader is closed.
Also, in practice, is it really so hard for the app to figure out
which SR goes to which of their caches? Isn't this "typically" a
containsKey against the app level caches...?