[
https://issues.apache.org/jira/browse/SOLR-9440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227172#comment-16227172
]
Tomás Fernández Löbbe commented on SOLR-9440:
---------------------------------------------
Thanks for looking at this Shalin!
{code:java}
if (v.canBeRemoved()) {
watchedCollectionStates.remove(collection);
lazyCollectionStates.put(collection, new LazyCollectionRef(collection));
reconstructState.set(true);
{code}
I'm wondering if we need some synchronization here, with
{{registerCollectionStateWatcher}} and also to make sure the
{{watchedCollectionStates.remove}} and {{lazyCollectionStates.put}} is done
atomically?
{code}
- private ConcurrentHashMap<String, CollectionWatch> collectionWatches = new
ConcurrentHashMap<>();
+ public ConcurrentHashMap<String, CollectionWatch> collectionWatches = new
ConcurrentHashMap<>();
{code}
Is this only for testing purposes?
> ZkStateReader on a client can cache collection state and never refresh it
> -------------------------------------------------------------------------
>
> Key: SOLR-9440
> URL: https://issues.apache.org/jira/browse/SOLR-9440
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Reporter: Shalin Shekhar Mangar
> Assignee: Shalin Shekhar Mangar
> Fix For: 6.7, 7.0, master (8.0)
>
> Attachments: SOLR-9440.patch, SOLR-9440.patch
>
>
> I saw this while writing a test case for SOLR-9438. The collection1
> collection which was in stateFormat=2 was somehow caching the
> CloudSolrClient's ZkStateReader such that the returned cluster state
> contained the collection state. However this collection was neither watched
> nor lazy so any call to waitForRecoveriesToFinish would see stale state and
> loop until timeout.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
