Thread-safety issue with Jersey Client in multi-threaded environments

[SeungMin369]

Description
When using GitLab4J API in a multi-threaded environment, some operations (e.g. connectionTest() or getVersion()) may fail intermittently due to the underlying Jersey Client sharing resources across threads.

Problem

Default JAX-RS client (Jersey) uses shared connection pools internally.

Concurrent calls like connectionTest() may cause race conditions, leading to intermittent failures.

GitLab4J (>=5.x) supports custom client injection, but this is not clearly documented, and many users perceive it as a library bug.

Example Code (to reproduce)
import org.gitlab4j.api.GitLabApi;
import org.gitlab4j.api.exceptions.GitLabApiException;

import java.util.stream.IntStream;

public class GitLabApiThreadSafetyTest {
public static void main(String[] args) throws Exception {
String url = "https://gitlab.example.com";
String token = "YOUR_PERSONAL_ACCESS_TOKEN";

    GitLabApi gitLabApi = new GitLabApi(url, token);

    // Run connectionTest() concurrently in multiple threads
    IntStream.range(0, 10).parallel().forEach(i -> {
        try {
            boolean ok = gitLabApi.getVersion() != null;
            System.out.println("Thread " + i + " success: " + ok);
        } catch (GitLabApiException e) {
            System.err.println("Thread " + i + " failed: " + e.getMessage());
        }
    });
}

}

Example Output (Observed)
Thread 0 success: true
Thread 1 failed: java.net.SocketException: Connection reset
Thread 2 success: true
Thread 3 failed: javax.ws.rs.ProcessingException: Premature EOF
Thread 4 success: true
...

Suggested Improvements

Documentation update

Clarify in README/Javadoc that Jersey Client may not be thread-safe under high concurrency.

Recommend OkHttp (or another proven thread-safe JAX-RS client) for multi-threaded workloads.

Convenience API

Provide a static factory method to easily create GitLabApi with OkHttp:

GitLabApi gitLabApi = GitLabApi.withOkHttp(ApiVersion.V4, url, token);

Tests

Add a multi-threaded test case (similar to the above) in the test suite to demonstrate stable behavior with OkHttp.

Benefits

Prevents confusion for new users.

Makes GitLab4J safer in real-world multi-threaded applications.

Backwards-compatible, minimal changes required.

[jmini]

I do not see where this library supports custom client injection… or support for an alternative library such as OkHttp…

Can you elaborate on that point?

[SeungMin369]

You're right — currently GitLab4J does not provide a way to inject a custom HTTP client or replace Jersey with an alternative implementation like OkHttp. My earlier wording was misleading; this should have been framed as a feature request rather than something that already exists.

Here’s why I believe this would be valuable:

Documentation: Make it clear in the README/Javadoc that GitLab4J is tightly coupled to Jersey and does not expose a way to configure other HTTP clients.

Feature request: Add support for custom client injection, e.g., a factory method such as GitLabApi.withCustomClient(...) or GitLabApi.withOkHttp(...).

Practical benefits: Improved stability in multi-threaded environments, reduced confusion for new users, and maintained backward compatibility.

So to clarify: this functionality doesn’t exist today, but adding it would make GitLab4J more robust and flexible for real-world usage.

[jmini]

Ok very clear.

This goes in the same direction as #924 feel free to join this discussion.

Since the conversion in 2 modules (see #1067) what you can do is to use the model module and write the http calls yourself.

[SeungMin369]

Thanks for the clarification. I understand now that this aligns with #924 and that the recommended approach is to use the model module and write the HTTP calls directly. I’ll follow that direction. Appreciate the guidance!