[
https://issues.apache.org/jira/browse/SOLR-5474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13841922#comment-13841922
]
Timothy Potter commented on SOLR-5474:
--------------------------------------
As Noble mentions above, this approach needs a time-to-live (TTL) timeout for
cached collection state. For this, I'm thinking of keeping an additional long
property along with the cached state that holds the timestamp of when the state
was last loaded from ZooKeeper. An age is computed when objects are requested
from the cache and if the age is older than a configured TTL, then the object
is removed from the cache and null is returned. Thinking something like the
following internal private class ...
class CachedDocCollection {
private DocCollection cached;
private long cachedAt;
boolean isExpired(long ttl) {
return (System.currentTimeMillis() - cachedAt) > ttl;
}
}
This approach has the benefit of not needing any new dependencies (such as
Guava's cache) and doesn't require a background thread to do cache housekeeping.
This has the downside of computing an age on each "get", which I don't think is
a big deal because state is probably not going to be requested all that
frequently.
> 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: [email protected]
For additional commands, e-mail: [email protected]
