I am planning and building up a test system with Solr 4.0, for my
eventual upgrade. I have not made a lot of progress so far, but I have
come across a potential problem.
I have seen that setQueryType is being deprecated in favor of
setRequestHandler, and that the recommendation now is to use handler
names starting with /, and they will be used in the URL instead of
/select. Further, SOLR-3161 makes it so that a qt parameter with a
leading / won't work.
In order to avoid statistics inflation, I configure all
testing/monitoring to use a separate handler that I call "lbcheck" (for
load balancer check), using the qt parameter. The PingRequestHandler
(which is what the load balancer checks every five seconds) includes qt
parameter, set to lbcheck. The lbcheck handler on my broker core
includes a shards.qt parameter, set to lbcheck.
If I follow the conventions as I understand them, I will be changing
lbcheck to /lbcheck, but I have not found a way so far to specify a
handler when using shards, or in the PingRequestHandler. The only
option is qt and/or shards.qt, but apparently a leading slash will not
be allowed there.
A thought that just occurred to me is to let all monitoring use the
standard request handler, and configure a new request handler called
/search to handle all requests from the application. By upgrading SolrJ
before Solr, I can use setRequestHandler to point at the new handler,
and I can even set up the new handler in Solr 3.5 before the upgrade.
Does this sound at all reasonable?
I think it may be necessary to file a JIRA so that when a handler is
configured to ultimately send requests to another handler
(PingRequestHandler, shards, etc.), you can change from /select to
/whatever. Does such a JIRA already exist?
Thanks,
Shawn
- Fallout from the deprecation of setQueryType Shawn Heisey
-
