Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.4
-
Component/s: None
-
Labels:None
Description
The firstSearcher and newSearcher events call the regular search component chain, but are special cases. They should identify themselves by passing in a parameter indicating their type. This way, for instance, the sharding component could know to ignore the &shards parameter, which currently causes Solr to hang if it is present in the firstSearcher query string.
Issue Links
- blocks
-
SOLR-1277
Implement a Solr specific naming service (using Zookeeper)
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
i think we make QuerySenderListener pass in a special param (init=newSearcher or init=firstSearcher), and i think we document that param, and i think we let people who implement their own SolrEventListeners worry about sending that param themselves if they want/need to...
If we do it right, we can leave it so people can explicitly override the param in the solrconfig.xml (ie: init=none) so people can hide the fact that it's a warming query if they really, really, want to.
Adds CommonParams.EVENT value to specify an event and constants for NEW_SEARCHER and FIRST_SEARCHER. Implements test for checking this (it's "mocking" ugly)
Also added documentation
I plan on committing in a couple of days.
Just a quick and petty comment:
+ public static final String NEW_SEARCHER = "newSrchr";
+ public static final String FIRST_SEARCHER = "frstSrchr";
No need to abbreviate so obtusely! "newSearcher" and "firstSearcher" pretty please.
No need to abbreviate so obtusely! "newSearcher" and "firstSearcher" pretty please.
+1
and why not "evt" changed to "event'
1. i don't know if these params are really common enough to belong in common .. the need to pay attention to them actually seems fairly uncommon, so i would suggest putting them in their own namespace.
1. skimming the patch it wasn't clear why you needed to write MockQuerySenderListener ... can't you just have a request handler that records whether it got newSearcher & firstSearcher flagged requests and then ask it (ask it once after startup, then send a commit and ask it again)?
No need to abbreviate so obtusely! "newSearcher" and "firstSearcher" pretty please.
Dang! That's fine by me, but there seems to be two camps in Solr-land, those who abbreviate and those who don't.
skimming the patch it wasn't clear why you needed to write MockQuerySenderListener ... can't you just have a request handler that records whether it got newSearcher & firstSearcher flagged requests and then ask it (ask it once after startup, then send a commit and ask it again)?
Actually, this is a good point, I need to modify the addEventParams() method to make a copy of the named list and then add the value, because the values get stored on the NamedList.
Fixed the names. Plan on committing in a day or two.
Committed revision 801417.
Bulk close for Solr 1.4
The problem I'm seeing here is that anyone can implement a SolrEventListener. How do we enfoce that the parameter is sent along?