[
https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14652366#comment-14652366
]
Scott Blum commented on SOLR-5756:
----------------------------------
1) Great catch, totally missed that.
2) Sure, not a problem. I thought it was kind of implied by the classname
(StateWatcher / ClusterStateWatcher) but explicit methods are always good.
3) Yes, but in the 99% case (no external state exists) the getData call fails,
no watcher is left on the node, and everything should just clean itself up. I
don't think this adds much additional overhead considering that
getStateFormat2CollectionNames() checks existence on *every* collection for a
state.json, even ones that are not "interesting", and this happens on every
update, not just on startup which is where the initial set of StateWatchers get
created. So I think lower-hanging fruit would be to optimize the
updateFromSharedClusterState -> getStateFormat2CollectionNames() code path. I
would love to talk more about how/why the rest of the system relies on the
lazy-loading bits.
4) I don't think I quite follow, let's discuss on IRC.
> A utility API to move collections from internal to external
> -----------------------------------------------------------
>
> Key: SOLR-5756
> URL: https://issues.apache.org/jira/browse/SOLR-5756
> Project: Solr
> Issue Type: Bug
> Reporter: Noble Paul
> Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-5756-trunk.patch, SOLR-5756-vs-5.2.1.patch
>
>
> SOLR-5473 allows creation of collection with state stored outside of
> clusterstate.json. We would need an API to move existing 'internal'
> collections outside
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
