[
https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901449#comment-16901449
]
Andrzej Bialecki commented on SOLR-13677:
------------------------------------------
bq. usually close is called always
:D There's no hard guarantee in any of these scenarios, just a degree of
likelihood.
I think that the patch over-complicates things by keeping an explicit reference
to the gauges. It should not be needed if we properly use the {{tag}} argument
when registering gauges.
The {{tag}} attribute was added to solve a problem of non-deterministic order
of gauge registration during core reload - the new core would already register
some of the new gauges but the old core would linger for a while and when it
tried to unregister gauges with the same names it would unregister the new ones
instead of the old ones.
So the important thing about the {{tag}} argument in
{{SolrMetricManager.registerGauge}} and {{SolrMetricManager.unregisterGauges}}
is this: the tag represents an object or a group of objects with the same
life-cycle. Until now the tag was generated by {{SolrCore}} and passed to all
its components because they had the same lifecycle. Also, it was {{SolrCore}}
(via {{SolrCoreMetricManager}}) that would call {{unregisterGauges}} on behalf
of all its components.
Now, if the life-cycle of components is different from that of {{SolrCore}}
then we need to make sure of two things:
* the {{tag}} properly represents the object or group of objects with the same
life-cycle - so if eg. SolrCache-s can be re-loaded without reloading SolrCore
then they should no longer use the same tag as their parent SolrCore. Instead
they should generate their own tags.
* each component must be now responsible for unregistering its own gauges, as
identified by its own tag. We can strongly encourage implementors to do this in
each component's {{AutoCloseable.close()}} but I don't see any easy way to
actually enforce it.
This approach doesn't require keeping actual references to gauges in each
component.
For convenience we could also extend the concept of {{tag}} so that it's
multi-valued - eg. a cache would use its own tag and the parent SolrCore-s tag.
This way both the cache and the SolrCore could each easily unregister gauges
that they (or their parent) created.
> All Metrics Gauges should be unregistered by the objects that registered them
> -----------------------------------------------------------------------------
>
> Key: SOLR-13677
> URL: https://issues.apache.org/jira/browse/SOLR-13677
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
> Reporter: Noble Paul
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The life cycle of Metrics producers are managed by the core (mostly). So, if
> the lifecycle of the object is different from that of the core itself, these
> objects will never be unregistered from the metrics registry. This will lead
> to memory leaks
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
