Message-ID: <gh-pgjdbc-pgjdbc-3089-c1887392244@github.com>
From: "embuc (@embuc)" <noreply+embuc@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Thu, 11 Jan 2024 15:15:04 +0000
Subject: Re: [pgjdbc/pgjdbc] issue #3089: Metaspace Memory leak: Thread.inheritedAccessControlContext
In-Reply-To: <gh-pgjdbc-pgjdbc-3089@github.com>
References: <gh-pgjdbc-pgjdbc-3089@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: embuc
X-GitHub-Comment-Id: 1887392244
X-GitHub-Comment-Type: issue_comment
X-GitHub-Edited-At: 2024-01-11T15:18:21Z
X-GitHub-Issue: 3089
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/3089#issuecomment-1887392244
Content-Type: text/plain; charset=utf-8

I looked around a bit now that i have cloned the code and omitting the Cleaner (Java's and/or LazyCleaner) and calling the close directly on the queryExecutor works. Or should I say does not block the GC during the hot reload.  I was thinking that this would be interesting to explore: "The cleaning action could be a lambda but all too easily will capture the object reference, by referring to fields of the object being cleaned, preventing the object from becoming phantom reachable. Using a static nested class, as above, will avoid accidentally retaining the object reference.

Cleaning actions should be prepared to be invoked concurrently with other cleaning actions. Typically the cleaning actions should be very quick to execute and not block. If the cleaning action blocks, it may delay processing other cleaning actions registered to the same cleaner" <- This is from the API docs.

Edit: Just to be clear after this wall of text:  42.7.2-SNAPSHOT with calling close on queryExecutor (in PgConnection#close()) works as expected regarding the memory leak.