: I believe it's common to configure firstSearcher & newSearcher similarly.
: The duplication in configuration (e.g. of warming queries) is annoying.
: Wouldn't it make sense for a "first searcher" event to be considered *not
: only* the "first" searcher but also inherently a "new" searcher as well?
I think that *could* be fine ... but it may also cause some backcompat
problems for people who currently (intentionally) double register an
"expensive" plugin? (because now it's going to be invoked twice on
firstSearcher)
Really the event listener API in general is kind of weird and if we're
going to change the semantics of when they are called, we might also want
rethink what a "V2" of it's API (and registration syntax) look like and
when eactly it gets called in a "modern" solr-cloud based collection.
FWIW...
As an example of how much nuance is required for an event listener to know
"when" it's being called, here is the start of the newSearcher() method in
one of my custom event listeners that I have that only wants to run
exactly once against the first (usable) searcher of a replica...
@Override
public final void newSearcher(SolrIndexSearcher newSearcher,
SolrIndexSearcher currentSearcher) {
// NOTE: There are a few edge cases we have to be careful about:
// 1) There is no way for this code to tell if it's been "registered" as a
"firstSearcher" or a "newSearcher"
// 2) Most solr plugins check `null == currentSearcher`, but in NRT
recovery situations, "firstSearcher" registered listeners can see that multiple
times
// (the first time when reading current disk, the second just before
finishing recovery)
// 3) In the case of new PULL replicas, the "firstSearcher" events may use
IndexReaders that have never replicated, and only "newSearcher" events get the
"real" index
//
// Because of this, the code in this method:
// a) expects to be registered as both a "firstSearcher" and "newSearcher"
event listener
// b) considers a non-null currentSearcher w/a "Solr commit version" ==
null to be a "firstSearcher" situation.
//
// This helps ensure that we always get run against the *real*
"firstSearcher" (exposed when our replica goes active).
//
final boolean firstSearcher =
Objects.isNull(getCommitVersion(currentSearcher));
...
...and in practice i don't even use the solrconfig.xml syntax to register
instances of this listener -- instead I have a RequestHandler whose
inform(SolrCore) creates a single instance of my custom listener (because
it's big and maintains a lot of state so i only want one of them) and
registers that same instance for both types of event callbakcs...
// psuedocode
@Override
public void inform(SolrCore core) {
if (myConfigSaysRegisterListener(this.initArgs)) {
final MyBigFancyListener listener = new MyBigFancyListener(this);
core.registerFirstSearcherListener(listener);
core.registerNewSearcherListener(listener);
}
}
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
