patsonluk commented on PR #1477: URL: https://github.com/apache/solr/pull/1477#issuecomment-1516770497
> @patsonluk as it is mutating an existing Object, there is a small period during which the state of a given replica is unpredictable . some replicas of the collection would fetch state from old PRS and some will point to new PRS > > The question is, what did we achieve with this change? Thank you for the comments/questions @noblepaul! Yes you are correct that mutating the prs in `DocCollection#copyWith(PerReplicaStates) with `this.prsSupplier.prs = newPerReplicaStates` would set the actual prs instance in one place! TBH, i did find such design a bit hard to trace when the PRS state mutates in `Replica` as such state is kept outside of `Replica` and modified in `DocCollection`. I guess that is a reasonable trade-off since `DocCollection/Slice/Replica` are mutable for PRS enabled collection and if we want to keep using the same instances for PRS updates, this is likely the best we could do, so let's just keep your existing implementation! 😊 The goal of this PR is make the loading/fetching of PRS states a bit more deterministic - ie, always fetch before the construction of `DocCollection` instead of relying on implementation. Currently it's `DocCollection ctor -> Slice#setPrsSupplier -> Slice#findLeader() -> Replica#isLeader() -> PrsSuppler#get` I will see if we can achieve that with the Supplier still in place for `DocCollection/Slice/Replica`. Will ping you again once the change is made. Thank you again! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
