[
https://issues.apache.org/jira/browse/SOLR-8330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037606#comment-15037606
]
Ishan Chattopadhyaya commented on SOLR-8330:
--------------------------------------------
The MethodHandles.lookup() creates an extra object for the Lookup inner class
of MethodHandles.
Isn't it memory/gc wise expensive, esp. given that some of the shortlived,
often created objects (like AtomicUpdateDocumentMerger,
DistributedUpdateProcessor etc.), would be creating their own logger, thus
implying many extra MethodHandles.Lookup objects for every request? Is that a
significant problem, or am I over estimating the problem?
> Restrict logger visibility throughout the codebase to private so that only
> the file that declares it can use it
> ---------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
> Issue Type: Sub-task
> Affects Versions: Trunk
> Reporter: Jason Gerlowski
> Assignee: Anshum Gupta
> Labels: logging
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8330-combined.patch, SOLR-8330-detector.patch,
> SOLR-8330-detector.patch, SOLR-8330.patch, SOLR-8330.patch, SOLR-8330.patch,
> SOLR-8330.patch, SOLR-8330.patch, SOLR-8330.patch, SOLR-8330.patch
>
>
> As Mike Drob pointed out in Solr-8324, many loggers in Solr are
> unintentionally shared between classes. Many instances of this are caused by
> overzealous copy-paste. This can make debugging tougher, as messages appear
> to come from an incorrect location.
> As discussed in the comments on SOLR-8324, there also might be legitimate
> reasons for sharing loggers between classes. Where any ambiguity exists,
> these instances shouldn't be touched.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
