[
https://issues.apache.org/jira/browse/SOLR-18456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18116573#comment-18116573
]
Chris M. Hostetter commented on SOLR-18456:
-------------------------------------------
there are some good comments in the history of PR#4917 and PR#4902 about the
idea of writing robust tests that "look for" leaked objects.
One thing that's alluded to in those discussions but has no concrete solution
in either conversation is the non-determinism of waiting for GC to happen.
I would like to point out that the solution to this kind of problem – far
better then a dumb "while WeakReference.get() !=null: sleep" anti-pattern, is
to either create WeakReferences with a ReferenceQueue that the test then
"polls" for completion (using {{{}remove(timelimit){}}}) .... or .... if we
want to be hard core certain that the object has _actually_ been GCed: use a
java.lang.ref.Cleaner to register a callback for once the Object is only
phantomly reachable (and that callback can trigger a semaphore that the test
thread waits on)
simplest approach probably being something like...
{noformat}
final ReferenceQueue waitForIt = new ReferenceQueue();
// the WeakRef created later must be reachable for entire test scope
final AtomicReference<WeakRefrence<SolrIndexSearcher>> ref = new
AtomicReference<>();
getCore().withSearcher(s -> { ref.set(new WeakReference(s, waitForIt)); })
// do stuff that might cause memory leak
// do stuff that should create a new searcher for the core
// Suggest immediate GC...
System.gc()
final WeakReference done =
waitForIt.remove(absolutelyBiggestTimeoutAllowedByTest);
assertTrue(done.referseTo(null));
assertEquals(ref.get(), done)
{noformat}
> Route all observable metric registration through SolrMetricsContext
> -------------------------------------------------------------------
>
> Key: SOLR-18456
> URL: https://issues.apache.org/jira/browse/SOLR-18456
> Project: Solr
> Issue Type: Improvement
> Reporter: Matthew Biscocho
> Priority: Minor
>
> SOLR-18442 was a leak caused by a single observable gauge whose registration
> never reached SolrMetricsContext's closeables list, so its callback was never
> unregistered and pinned every SolrIndexSearcher ever opened.
> We should better protect devs from this in the future or if new observable
> instruments get created by making it impossible to register an observable
> metric without cleanup.{{{}{}}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
