[
https://issues.apache.org/jira/browse/SOLR-5474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831910#comment-13831910
]
Timothy Potter commented on SOLR-5474:
--------------------------------------
I like the strategy of using a LazyCloudSolrServer as that keeps this "lazy"
mode de-coupled from the current implementation, giving Solr users the choice
based on their environment. However, while planning an implementation strategy
for this, I discovered that some of the core cloud classes in the
org.apache.solr.common.cloud package, such as CloudSolrServer and
ZkStateReader, are closed for extension because all of the member variables one
would need access to are marked private. It seems reasonable that one would
want to extend these classes, if for some other reason than this ticket alone.
Curious on whether I can plan to mark the members of the core classes protected
instead of private or should an implementation of this ticket leave all
existing cloud code un-touched even if that leads to copy-and-paste reuse in
some cases? Immediately, I can see needing to change some access modifiers for
CloudSolrServer, ZkStateReader, and ClusterState.
> Have a new mode for SolrJ to not watch any ZKNode
> -------------------------------------------------
>
> Key: SOLR-5474
> URL: https://issues.apache.org/jira/browse/SOLR-5474
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
> Reporter: Noble Paul
>
> In this mode SolrJ would not watch any ZK node
> It fetches the state on demand and cache the most recently used n
> collections in memory.
> SolrJ would not listen to any ZK node. When a request comes for a collection
> ‘xcoll’
> it would first check if such a collection exists
> If yes it first looks up the details in the local cache for that collection
> If not found in cache , it fetches the node /collections/xcoll/state.json and
> caches the information
> Any query/update will be sent with extra query param specifying the
> collection name , shard name, Role (Leader/Replica), and range (example
> \_target_=xcoll:shard1:L:80000000-b332ffff) . A node would throw an error
> (INVALID_NODE) if it does not the serve the collection/shard/Role/range combo.
> If SolrJ gets INVALID_NODE error it would invalidate the cache and fetch
> fresh state information for that collection (and caches it again)
> If there is a connection timeout, SolrJ assumes the node is down and re-fetch
> the state for the collection and try again
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
