[
https://issues.apache.org/jira/browse/SOLR-9057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268582#comment-15268582
]
Joel Bernstein commented on SOLR-9057:
--------------------------------------
OK, I just saw the description of smart caching on SOLR-8327 (below). I hadn't
realized that this approach replaced watches either.
# a request for a collection comes to solrj
# look up in local cache . If not available read from ZK and populate local
cache
# make a request to the server optimistically assuming that the data in cache
is latest. But
send extra information as a request parameter
(\_stateVer_=<coll-name>:<zk-version-of-state.json-in-cache>)
# at server. if this parameter is present, check locally if the version is
correct . If this
node serves this collection, it always has the latest state. So no ZK lookup is
necessary
# If the version at server is newer send the latest version of the state as a
part of the
payload
# solrj looks for this extra info in the payload. If there is no extra info,
the state it
has is the latest. nothing needs to be done. If the payload contains versions
of the state,
it means that the local version is stale, invalidate the cache
> CloudSolrClient should be able to work w/o ZK url
> -------------------------------------------------
>
> Key: SOLR-9057
> URL: https://issues.apache.org/jira/browse/SOLR-9057
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
> Reporter: Noble Paul
>
> It should be possible to pass one or more Solr urls to Solrj and it should be
> able to get started from there. Exposing ZK to users should not be required.
> it is a security vulnerability
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
