[
https://issues.apache.org/jira/browse/SOLR-18131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18119179#comment-18119179
]
Jan Høydahl commented on SOLR-18131:
------------------------------------
Won't this couple zk detail with a public API? Of course, the version could be
an opaque string, with no ZK ref.
I floated another idea on the list for using an event-stream (SSE) based API
for clusterstate, where clients will get a real time stream of cluster state
changes, e.g. a new list of live_nodes every time it changes. Problem is that
no single solr node has ZK watches for the entire state, only the collections
it hosts, so for such an event stream to be complete. Could have a pattern
where the overseer watches everything, then CSP could connect to the overseer.
But that would break down if cient is behind an external LB.
Probably, this idea with ids and invalidating caches is less expensive in terms
of network connection and traffic.
> SolrCloud should return HTTP header(s) of certain ZK node versions
> ------------------------------------------------------------------
>
> Key: SOLR-18131
> URL: https://issues.apache.org/jira/browse/SOLR-18131
> Project: Solr
> Issue Type: Sub-task
> Reporter: David Smiley
> Priority: Major
>
> (see parent issue) Solr should return an HTTP header of some ZK Stat version
> numbers of pertinent ZK nodes. Relates to ClusterState tracking. This
> enables a client to invalidate a cache of related information (perhaps
> CloudSolrClient / HttpClusterStateProvider) or similar for custom clients not
> using SolrJ.
> It could be JSON to hold multiple, or we use multiple headers. Need to
> decide on suitable name(s).
> All SolrCloud interaction can use this:
> live_nodes: ZK cversion (initial 'c' is for children)
> Interactions involving one (typical) or more collections can incorporate:
> collectionName: ZK version
> Interactions involving alias resolution can incorporate:
> aliases: ZK version
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]