[
https://issues.apache.org/jira/browse/SOLR-11511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-11511.
---------------------------------
Resolution: Fixed
Assignee: David Smiley
Fix Version/s: 7.2
I also made some other tweaks, largely driven by IDE warnings.
The main thing left I didn't touch that IntelliJ considers a bad practice is
the synchronized calls on local parameters and in this class that's
VersionBucket in a number of places. I'll let that be.
> 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
> 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: [email protected]
For additional commands, e-mail: [email protected]
