Affected module
Backend (openmetadata-service)
Describe the bug
Three resource leak bugs across openmetadata-service where streams and connections are opened but never closed, leaking file descriptors and TCP sockets.
Bug 1: SamlSettingsHolder — FileInputStream never closed
In SamlSettingsHolder.java, a FileInputStream is created inline and passed directly to keyStore.load() without being assigned to a variable or wrapped in try-with-resources:
KeyStore keyStore = KeyStore.getInstance("JKS");
keyStore.load(
new FileInputStream(securityConfig.getKeyStoreFilePath()), // ← NEVER CLOSED
securityConfig.getKeyStorePassword().toCharArray());
Since the stream is created inline, it cannot be closed later — the reference is lost immediately. This leaks a file descriptor every time SAML settings are loaded.
Bug 2: SamlValidator — HttpURLConnection never disconnected
In SamlValidator.validateIdpConnectivity(), an HttpURLConnection is opened to test the IdP SSO URL but conn.disconnect() is never called in any code path:
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
conn.setRequestMethod("GET");
conn.setConnectTimeout(5000);
conn.setReadTimeout(5000);
int responseCode = conn.getResponseCode();
// ... multiple if/else branches processing the response ...
// ← conn.disconnect() NEVER called in ANY code path
Additionally, readResponseSnippet() reads from the connection's error/input stream without closing it. Every SAML IdP connectivity validation leaks a TCP socket.
Bug 3: IndexResource — InputStream and BufferedReader never closed
In IndexResource.java, both the constructor and the static getIndexFile() method open an InputStream and wrap it in a BufferedReader, but neither is ever closed:
// Constructor (same pattern in getIndexFile):
InputStream inputStream = getClass().getResourceAsStream("/assets/index.html");
indexHtml = new BufferedReader(new InputStreamReader(inputStream))
.lines()
.collect(Collectors.joining("\n"));
// ← BOTH InputStream and BufferedReader NEVER CLOSED
Additionally, there's no null check — if /assets/index.html is missing from the classpath, this throws an unhelpful NPE.
To Reproduce
Bug 1:
- Configure SAML authentication with a JKS keystore
- Each SAML settings load/reload leaks one OS file descriptor
- Under repeated SAML reconfigurations, file descriptor count grows
Bug 2:
- Configure SAML SSO validation
- Each call to
validateIdpConnectivity() leaks one TCP socket
- Under repeated SAML validation (e.g., testing configurations), socket count grows
Bug 3:
- Start the OpenMetadata server
- Both the
IndexResource constructor and any call to getIndexFile() leak classpath streams
- Minor impact since these run at startup, but violates resource management best practices
Expected behavior
All three should use try-with-resources to ensure streams and connections are properly closed:
- Bug 1:
FileInputStream wrapped in try-with-resources before passing to keyStore.load()
- Bug 2:
HttpURLConnection wrapped in try-finally with conn.disconnect() in the finally block
- Bug 3:
InputStream and BufferedReader wrapped in try-with-resources with a null check
These patterns are already used correctly elsewhere in the codebase (e.g., SchemaFieldExtractor.getAllEntityTypes(), AutoPilotApp, JsonLdTranslator, OntologyLoader).
Version:
- OpenMetadata version: main branch (latest)
Additional context
This is a continuation of resource leak cleanup work from PR #27063, which fixed similar InputStream leaks in SchemaFieldExtractor.loadMainSchema() and SchemaFieldExtractor.loadSchema(). The same try-with-resources pattern applies here.
Related prior work:
Affected module
Backend (openmetadata-service)
Describe the bug
Three resource leak bugs across
openmetadata-servicewhere streams and connections are opened but never closed, leaking file descriptors and TCP sockets.Bug 1: SamlSettingsHolder — FileInputStream never closed
In
SamlSettingsHolder.java, aFileInputStreamis created inline and passed directly tokeyStore.load()without being assigned to a variable or wrapped in try-with-resources:Since the stream is created inline, it cannot be closed later — the reference is lost immediately. This leaks a file descriptor every time SAML settings are loaded.
Bug 2: SamlValidator — HttpURLConnection never disconnected
In
SamlValidator.validateIdpConnectivity(), anHttpURLConnectionis opened to test the IdP SSO URL butconn.disconnect()is never called in any code path:Additionally,
readResponseSnippet()reads from the connection's error/input stream without closing it. Every SAML IdP connectivity validation leaks a TCP socket.Bug 3: IndexResource — InputStream and BufferedReader never closed
In
IndexResource.java, both the constructor and the staticgetIndexFile()method open anInputStreamand wrap it in aBufferedReader, but neither is ever closed:Additionally, there's no null check — if
/assets/index.htmlis missing from the classpath, this throws an unhelpful NPE.To Reproduce
Bug 1:
Bug 2:
validateIdpConnectivity()leaks one TCP socketBug 3:
IndexResourceconstructor and any call togetIndexFile()leak classpath streamsExpected behavior
All three should use try-with-resources to ensure streams and connections are properly closed:
FileInputStreamwrapped in try-with-resources before passing tokeyStore.load()HttpURLConnectionwrapped in try-finally withconn.disconnect()in the finally blockInputStreamandBufferedReaderwrapped in try-with-resources with a null checkThese patterns are already used correctly elsewhere in the codebase (e.g.,
SchemaFieldExtractor.getAllEntityTypes(),AutoPilotApp,JsonLdTranslator,OntologyLoader).Version:
Additional context
This is a continuation of resource leak cleanup work from PR #27063, which fixed similar
InputStreamleaks inSchemaFieldExtractor.loadMainSchema()andSchemaFieldExtractor.loadSchema(). The same try-with-resources pattern applies here.Related prior work: