[
https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13984507#comment-13984507
]
Timothy Potter commented on SOLR-5473:
--------------------------------------
Hi Mark,
Just wanted to get your input on the watcher approach I described above:
bq. In terms of what's watched and what is not watched, this patch includes
code from 5474 (as they were too intimately tied together to keep separated)
which doesn't watch collection state changes on the client side. Instead the
client relies on a stateVer check during request processing and receives an
error from the server if the client state is stale. I too think this is a
little controversial / confusing and maybe we don't have to keep that as part
of this solution. It was our mistake to merge those two into a single patch. We
originally were thinking 5474 was needed to keep the number of watchers on a
znode to a minimum in the event of many clients using many collections.
However, I do think this feature can be split out and dealt with in a better
way, if at all. In other words, split state znodes are watched from server and
client side.
Basically, our approach is that each core on the cluster-side only watches the
state znode for the collection it is participating in and on the client-side,
the CloudSolrServer is not watching any state znodes and instead rely on cached
DocCollections and stale state checks on the server side when processing client
requests. Do you have any concerns with us moving forward with this approach?
Alternatively, the CloudSolrServer on the client-side can use watchers on state
znodes after dynamically fetching them from the server when a request for a new
collection comes in.
> Make one state.json per collection
> ----------------------------------
>
> Key: SOLR-5473
> URL: https://issues.apache.org/jira/browse/SOLR-5473
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 5.0
>
> Attachments: SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473_undo.patch,
> ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log
>
>
> As defined in the parent issue, store the states of each collection under
> /collections/collectionname/state.json node
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
