Intermittent "Connection reset by peer" when reusing idle OkHttp connection with Microsoft Graph Java SDK behind HTTP proxy

[AbdulAlSowdhS]

Describe the bug

Hi Team,

We are facing an intermittent issue when using Microsoft Graph Java SDK behind a corporate HTTP proxy.

Environment:

Java 17
Spring Boot
Microsoft Graph SDK 6.56.0
Azure Identity 1.16.0
Azure Core HTTP OkHttp 1.11.12
OkHttp Client
Corporate HTTP Proxy
Scheduler running every 5 minutes

Issue Pattern:

Application Startup:

New TCP connection created
TLS handshake successful
Graph API call successful

Second Scheduler Run (5 minutes later):

Existing connection is reused
No new TCP connection created
TLS handshake attempted
Connection reset by peer
Request fails

Third Scheduler Run:

New TCP connection created
TLS handshake successful
Graph API call successful

The Graph API being called is MailFolders.

Authentication is successful and token acquisition does not fail.

Azure Identity logs show:

ClientSecretCredential => getToken() SUCCESS

The failure occurs during the Graph API request after token acquisition.

Exception:

java.net.SocketException: Connection reset by peer

Wireshark Analysis:

Successful Request:

New TCP connection
TLS handshake
Graph request succeeds

Failed Request:

Existing connection reused
No new TCP connection created
TLS handshake attempted
Connection reset by peer

Next Request:

New TCP connection created
TLS handshake successful
Request succeeds

Additional Observation:

When retryOnConnectionFailure(true) is enabled, OkHttp closes the failed connection, creates a new connection and the retry succeeds.

Questions:

Is GraphServiceClient expected to reuse idle pooled OkHttp connections after several minutes?
Is there a recommended ConnectionPool configuration for long-running scheduled workloads?
Is there any recommended configuration for Graph SDK when using an HTTP proxy?
Has this behavior been observed previously with Graph SDK 6.56.0?

This application previously worked with the same code and configuration and the issue started only recently without any application code changes.

Expected behavior

The Graph API request should succeed on every scheduler execution.

When an idle connection becomes invalid, Graph SDK / OkHttp should either:

Create a new connection automatically, or
Retry using a new connection without failing the request.

We expect consistent behavior across all scheduler executions without intermittent "Connection reset by peer" errors.

How to reproduce

1. Create a Spring Boot application using Microsoft Graph Java SDK 6.56.0, Azure Identity 1.16.0 and azure-core-http-okhttp 1.11.12.
2. Configure GraphServiceClient with OkHttpClient and an HTTP proxy.
3. Create a scheduler that runs every 5 minutes.
4. Call Microsoft Graph MailFolders API during every scheduler execution.
5. Start the application.
6. Observe that the first execution succeeds.
7. Wait for the second scheduler execution.
8. The second execution intermittently fails with:

java.net.SocketException: Connection reset by peer

1. Wait for the next scheduler execution.
2. The third execution succeeds again.

Wireshark observations:

• First execution creates a new TCP connection and succeeds.
• Second execution reuses an existing connection and fails with connection reset.
• Third execution creates a new TCP connection and succeeds.

The issue is reproducible only when connection reuse occurs after an idle period.

SDK Version

6.56.0

Latest version known to work for scenario above?

Unknown. The same application and configuration previously worked successfully. The issue started recently without application code

Known Workarounds

We found that enabling retryOnConnectionFailure(true) reduces the occurrence of the issue. When the connection reset occurs, OkHttp closes the failed connection, creates a new connection and retries the request successfully.
We are also testing ConnectionPool configuration with a shorter idle timeout to prevent reuse of older idle connections.
Additionally, the next scheduler execution usually succeeds because a completely new TCP connection is created.
The root cause is still under investigation.

Debug output

connection-reset-log-summary.txt

Application startup:

New TCP connection created
TLS handshake completed successfully
Graph MailFolders API call successful

Second scheduler execution (approximately 5 minutes later):

Existing connection reused
No new TCP connection created
TLS handshake attempted
Connection reset by peer
Request failed

Third scheduler execution:

New TCP connection created
TLS handshake completed successfully
Graph MailFolders API call successful

Authentication behavior:

Token acquisition succeeds successfully
ClientSecretCredential getToken returns SUCCESS
Failure occurs after token acquisition during Graph API execution

Observed exception:

java.net.SocketException: Connection reset by peer

Relevant stack trace location:

Http1ExchangeCodec.readResponseHeaders
Exchange.readResponseHeaders
MailFoldersRequestBuilder.get

Wireshark observations:

Successful execution:

New TCP connection
TLS handshake successful
Request successful

Failed execution:

Existing connection reused
No new TCP connection created
TLS handshake attempted
Connection reset by peer

Next execution:

New TCP connection created
TLS handshake successful
Request successful

Additional observation:

When retryOnConnectionFailure(true) is enabled, the request succeeds because OkHttp creates a new connection and retries automatically.

Configuration

GraphServiceClient_Config.txt

OS:
AKS (Azure Kubernetes Service) running Linux based containers in production
Microsoft Graph Java SDK application deployed as a containerized microservice
Local testing performed on Windows Server

Is it specific to this configuration?
Currently investigating.
Issue observed in AKS hosted microservice environment.
Corporate HTTP proxy is used in both environments.

Other information

We believe the issue may be related to connection reuse after an idle period.

Observations:

Scheduler runs every 5 minutes.
First Graph API call after application startup always succeeds.
Second scheduler execution intermittently fails with "Connection reset by peer".
Third scheduler execution succeeds again.

Based on Wireshark analysis:

Successful execution creates a new TCP connection and performs a successful TLS handshake.
Failed execution attempts to reuse an existing connection.
No new TCP connection is established during the failed execution.
TLS handshake is attempted and the connection is reset.
The next successful execution creates a new TCP connection and succeeds.

Additional observations:

Authentication is successful.
Azure Identity token acquisition succeeds.
Failure occurs during Graph API execution and not during token acquisition.

Workaround identified:

Enabling retryOnConnectionFailure(true) reduces the issue because OkHttp creates a new connection and retries successfully.
Reducing connection pool idle timeout also appears to reduce the occurrence.

Questions:

Is this expected behavior when GraphServiceClient is used with OkHttp and a corporate HTTP proxy?
Is there a recommended connection pool or retry configuration for long-running scheduler workloads?
Is there any known issue involving reuse of idle connections in this scenario?

GraphServiceClient_Config.txt