Connection Leak in JsonFactory.createParser(URL) on HTTP 404

[rahulkantyadav]

🐞 Bug Report: Connection Leak in JsonFactory.createParser(URL) on HTTP 404
Module: jackson-core
Class: JsonFactory
Method: createParser(URL url)

🧩 Description
The method createParser(URL) in JsonFactory opens a connection using URL.openStream(). For successful HTTP responses (e.g., 200 OK), the stream is passed to the parser, which eventually closes the connection. However, in failure scenarios (e.g., HTTP 404), a FileNotFoundException is thrown before the parser is created, and the connection is not closed, leading to resource leaks.

📄 Code Snippet

public JsonParser createParser(URL url) throws IOException, JsonParseException {
    IOContext ctxt = this._createContext(this._createContentReference(url), true);
    InputStream in = this._optimizedStreamFromURL(url); // May throw FileNotFoundException
    return this._createParser(this._decorate(in, ctxt), ctxt);
}

⚠️ Issue
When the URL returns 404, URL.openStream() throws FileNotFoundException.
The input stream is never passed to the parser, and hence never closed.
This causes connection leaks, especially in high-frequency access scenarios.

🧪 Reproduction Scenario
In our case, this issue was reproduced while using Jackson in an NSQ consumer. The consumer continuously invoked createParser(URL) to poll for topic metadata. When the topic did not exist, the server returned 404 repeatedly. This led to:

A large number of open connections
Eventual port exhaustion due to unclosed connections

✅ Expected Behavior
Connections should be closed even if the parser is not created.
Exception handling should ensure cleanup of resources.

💡 Suggestion
Instead of using URL.openStream(), consider using a connection-pooled HTTP client like:

HttpClient (Java 11+)
OkHttpClient (for broader compatibility)
These clients manage connections efficiently and help avoid resource exhaustion in high-load environments.

🧪 Environment
Jackson Version: 2.14.0
Java Version: 11+

[JooHyukKim]

I thinkJackson relying on HttpClient could create many dependency conflicts.
WDYT about simple try-catching to close the stream? @rahulkantyadav

[rahulkantyadav]

@JooHyukKim from api of lib, i am not sure if client can get reference of connection object to be used to close it. It has to be handled inside library itself as this is side effects of calling readTree(URL URL) of ObjectMapper. Can you share any example to support your answer

[JooHyukKim]

I was thinking something like this.

public JsonParser createParser(URL url) throws IOException, JsonParseException {
    IOContext ctxt = this._createContext(this._createContentReference(url), true);
    try {
          InputStream in = this._optimizedStreamFromURL(url); // May throw FileNotFoundException
     finally {
           // close here...
     }
    
    return this._createParser(this._decorate(in, ctxt), ctxt);
}

Instead of using URL.openStream(), consider using a connection-pooled HTTP client like:

HttpClient (Java 11+)
OkHttpClient (for broader compatibility)

Instead of suggested libs above. Because introducting another library would open door to other problems (like dependency conflict)

[rahulkantyadav]

Yes, this could be one solution. But again this piece of try finally code is within JsonFactory class of Jackson library only.. Right? And not client side.
Why I was saying to use different library was because it still doesn't make use of connection reuse

[cowtowncoder]

We will not be adding dependency to non-JDK http libraries, fwtw. That's a hard limit.

Ideally we perhaps should have removed URL-taking variants from Jackson 3.x, since this sort of falls outside of Jackson's core responsibilities. But that's bit late now.

[cowtowncoder]

This belongs in jackson-core, not here. Transferring.

[cowtowncoder]

Existing issue #803 seems related.

[rahulkantyadav]

@cowtowncoder ok thanks for sharing. But still not clear whether the issue is already addressed. If yes, what needs to be done from client side

[pjfanning]

@rahulkantyadav issue exists but it is not implemented
If this issue is a big concern for you, you can avoid all the Jacskon API methods that take URL inputs and use the equivalent methods that take InputStream inputs instead. You can create the InputStream and handle the exceptions that might happen when creating the InputStream.

[rahulkantyadav]

@pjfanning thanks for the update