(AI written): I'm reworking Solr's server-side use of SolrClientCache (the
cache behind streaming expressions, /export, /graph, /sql and the
cross-collection join). The direction I'd like to confirm:
A standalone (user-managed) Solr node may still talk to individual Solr
nodes addressed by HTTP URL, but it will no longer construct a
CloudSolrClient -- neither ZooKeeper-addressed (zkHost=) nor
HTTP-quorum-addressed (solrConnection=http://...).
Before I commit to that, I'd like to know whether anyone actually relies on
the current behavior. Below is what I believe works today in standalone
mode. Note that nothing here is covered by a test: every streaming/SQL/join
test I can find runs against SolrCloud, and the only non-cloud solrconfig
that declares /stream is never exercised. So the "works today" column is
mostly code reading, not observed behavior.
Would stop working (standalone only; all of these build a CloudSolrClient)
1. Streaming expressions that name a cluster explicitly, via /stream,
/graph or /export.
In standalone there is no default collection or connection
(StreamHandler only sets those when ZooKeeper-aware), so each expression
would have to carry zkHost= or solrConnection= itself. That covers search,
facet, facet2D, random, stats, timeseries, topic, update, commit, delete,
knn, significantTerms, features, train/textLogit, nodes/gatherNodes,
shortestPath, scoreNodes.
Confidence: medium. Mechanically it looks possible; I have not seen it
used or tested.
2. jdbc("jdbc:solr://...") inside a streaming expression, and /sql.
/sql already flags itself as non-cloud in standalone, so it may be
refused before this matters.
Confidence: low. I have not traced either path fully in standalone.
3. Cross-collection join with zkHost= or solrConnection=.
Confidence: high that this is cluster-addressed and would be refused.
4. Cross-collection join with solrUrl=.
This one is URL-addressed and so isn't strictly covered by the rule
above, but I plan to require SolrCloud for cross-collection join as a
whole. The local side needs no cluster, yet the remote end must be
SolrCloud anyway, since a standalone /stream cannot resolve
search(collection, ...) without a default connection. That makes
standalone-to-cluster the only shape that could ever have worked.
Confidence: medium that it works today; high that the remote must be
SolrCloud.
Unaffected
- SolrJ applications and "bin/solr stream --execution local": these run in
a client JVM, not in the server, and are not restricted.
- Streaming expressions that never contact a cluster (echo, tuple, list,
let/select, math and eval functions).
- Everything in SolrCloud mode.
Question: does anyone run a standalone Solr that reaches a SolrCloud
cluster through these server-side features? If so, which, and how? If
nobody does, I'll make standalone refuse cluster connections and require
SolrCloud for cross-collection join.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
