patsonluk commented on code in PR #1242:
URL: https://github.com/apache/solr/pull/1242#discussion_r1061136542
##########
solr/solrj/src/java/org/apache/solr/common/cloud/DocCollection.java:
##########
@@ -139,30 +138,10 @@ public static String getCollectionPathRoot(String coll) {
* only a replica is updated
*/
public DocCollection copyWith(PerReplicaStates newPerReplicaStates) {
Review Comment:
Thanks i see what you mean now! 😅 I didn't notice the how the information
was shared/mutated by the same `prsSupplier`.
I guess what confused me was that I have always assumed Slice/Replica to be
immutable so it was unexpected on how the flow now works.
I do understand we are trying to avoid making copies here by reusing the
existing Slice/Shard instances, and it might then become inevitable to mutate
them.
Wondering whether the existing design (immutable/making copies of the
replica/shard on update) has caused any performance concern? Being immutable
does have certain advantages - such as thread safety and ease to read the flow
- considered that i just missed the shared prsSupplier details, this might not
be obvious of how changes are shared, as such linkage is built at the ctor of
`DocCollection` (that the same prsSupplier instance was assigned to
docCollection as well as the input slice/replica), which is outside of the
scope of Slice/Replica
--
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
