[
https://issues.apache.org/jira/browse/SOLR-11511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16234249#comment-16234249
]
ASF subversion and git services commented on SOLR-11511:
--------------------------------------------------------
Commit 1ff6084d8ee9fa26d3ca642d3379fc8fc7b31289 in lucene-solr's branch
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1ff6084 ]
SOLR-11511: minor: use existing fields in DURP: coreDesc, zkController,
collection
> Use existing private field in DistributedUpdateProcessor
> --------------------------------------------------------
>
> Key: SOLR-11511
> URL: https://issues.apache.org/jira/browse/SOLR-11511
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Affects Versions: master (8.0)
> Reporter: Gus Heck
> Assignee: David Smiley
> Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11511.patch
>
>
> The DistributedUpdateProcessor has a private instance field called cloudDesc.
> It is used in a few places, but most code navigates to CloudDescriptor from
> the request object instead.
> The fundamental question of this ticket, is this: is there any reason to
> distrust this field and do the navigation directly (in which case maybe we
> get rid of the field instead?) or can we trust it and thus should use it
> where we can. Since it is a private field only ever updated in the
> constructor, it's not likely to be changing out from under us. The request
> from which it is derived is also held in a private final field, so it very
> much looks to me like this field should have been final and should be used.
> This might or might not be a performance gain (depending on whether or not
> the compiler can optimize away something like this already), but it will be a
> readability and consistency gain for sure.
> Attaching patch to tidy this up shortly...
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
