[
https://issues.apache.org/jira/browse/SOLR-11511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235010#comment-16235010
]
ASF subversion and git services commented on SOLR-11511:
--------------------------------------------------------
Commit aa0286540f3648e39e1fb5a9e367fd41c175dccc in lucene-solr's branch
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=aa02865 ]
SOLR-11511: qualify inner type name for javadocs links to fix precommit
> 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
